1 REMOTE PURCHASING SYSTEM AND METHOD 

2 

3 CROSS-REFERENCE TO RELATED APPLICATION 

4 This application claims priority to copending U.S. Provisional Patent Application 

5 Serial No. 60/423,846, filed on November 5, 2002, the entire disclosure of which is 

6 incorporated herein by reference in its entirety. 

7 BACKGROUND OF THE INVENTION 

8 The present invention relates, generally, to the remote purchasing of products or 

9 services, and more particularly, to an enhanced system and method for the remote 

10 purchasing of products or services via a network, wherein a buyer is permitted to indicate 

1 1 as specific physical location where the products or services will be claimed and identify a 

12 third-party as the recipient of the products or services. 

13 Currently, there are many issues that arise for a person who would like to 



14 remotely purchase a beverage (or food product, or other item) for someone else. First, in 

1 5 typical cases, both the purchaser and the recipient must be physically present at a venue 

16 where the purchase transaction takes place. Therefore, the purchaser must be physically 

1 7 and temporally proximate to the target venue in order to purchase a beverage for someone 

18 at any given time. 



19 Furthermore, in many cases the person who would like to purchase a beverage 

20 may not be aware of the location of a suitable venue, or, more acutely, may not have 

21 information about the specific venues that the intended recipient considers suitable. In 

22 addition, even once the location of a venue suitable for purchasing a beverage in has been 



1 identified, there is, in some cases, a lengthy process of physically locating the venue, and 

2 in some cases a situation in which the venue is closed, too busy or otherwise inaccessible. 

3 Another issue facing a purchaser trying to go through this process is the fact that 

4 if the purchaser locates the venue, travels to the venue and the venue is open, there is no 

5 means of purchasing a beverage for another person without them physically being present 

6 at the time of purchase. In most cases there are no means to purchase a beverage for a 

7 later date, whereby the recipient of the beverage is able to collect the purchased beverage 

8 later that day or on even another day altogether. 

9 The above issues are multiplied if a person wants to buy several beverages for 

10 several different persons in different venues and on different days. The purchasing 

1 1 process would have to be repeated several times, and in the case where one would like to 

12 make several purchases at widely dispersed locations at roughly the same time, it 

1 3 therefore becomes an unattainable goal 

14 One known solution to these problems would be to telephone or visit a venue, 

15 provide payment and make an arrangement with staff at the venue for the recipient to 

16 claim said beverage at a future date. This solution would also require alerting the 

17 recipient in enough detail to claim the beverage and the venue in enough detail to 

18 positively identify the recipient. This solution suffers from the amount of effort and time 

19 involved, uncertainty about properly informing the recipient, uncertainty about whether 

20 the venue will truly honor the purchase, and many of the issues (such as identifying and 

21 contacting a suitable venue) as described above. 

22 Another known solution, which does not relate to the scope of the invention being 

23 discussed, would be to purchase a packaged form of beverage (a bottle of wine, a bag of 
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1 dried tea) that could be delivered to the recipient in any of the usual fashions. This 

2 solution does not typically involve a venue with a specific location as part of the claim 

3 transaction. 

4 From the venue's perspective, a very large problem with existing processes for 

5 purchasing drinks, as set forth above, is the loss of potential customers and earnings. 

6 Unless a venue has established some kind of remote purchasing service, they are losing 

7 out on potentially significant revenue generating opportunities and the opportunity for 

8 repeat business from new or existing customers. 

9 Another issue that a venue faces today is the issue of making consumers aware of 

10 its existence and establishing and maintaining relationships with existing and potential 

1 1 customers. As it stands today there are many means and medias for a venue to use as 

12 promotional and information tools, but the fact that there are so many creates a problem 

1 3 for the venue of identifying the effectiveness of many of the tools. Also, many of the 

14 media, such as yellow page advertisements, are static, in that they do not provide specific 

15 feedback to the venue about their effectiveness or interactivity with a potential customer 

16 and cannot be updated frequently. Every venue wishes to be found easily using different 

17 tools, but it is increasingly difficult to ensure the information is current (especially, e.g., 

18 if the venue hosts a calendar of events), accessible, and inexpensive for both venue owner 

1 9 and customer alike. 

20 Other issues facing venues are the desire to increase customer traffic and revenues 

21 and the desire to reduce overall marketing costs. Currently, most venues have a 

22 maximum capacity of persons set by the local authorities and thus can only increase 

23 revenues by increasing the number of patrons up to capacity, by increasing throughput, or 
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1 by increasing the profitability of customer purchases. Given that patrons cannot be 

2 increased past capacity or throughput increased beyond a certain physical limit, venue 

3 owners may be unable to increase their revenues beyond a certain point without adding 

4 new capacity or throughput capability. In addition, when a location is too busy it is likely 

5 to have an adverse effect on throughput. 

6 Therefore, it is desirable to provide a process and service that reduces the amount 

7 of time and effort required by a venue to attract and process customers wherever they 

8 may be. It is also a desire on the part of venues to be empowered when using media as an 

9 advertising tool. Allowing customers to purchase beverages without physical presence 

10 assists a venue in dealing with the issues described above. Remote purchasing creates a 

1 1 level of service to consumers unsurpassed in the industry today. 

12 In addition to customers and venues, other agents that are party to the above 

13 process face certain difficulties. Beverage manufacturers and distributors often do not 

14 receive direct information about consumer purchases, tastes and behavior from venues. 

15 When such information is received it is likely to be anecdotal rather than systematized. 

16 As well, marketing activities directed at consumers are not often made directly to 

17 consumers, but are proxied through the venues or various consumer-focused media 

18 channels. 

19 Marketers who would like to promote third-party products to the consumers who 

20 visit these venues also do not have a way to gather information or interact directly with 

21 these consumers in a remote fashion, but must be physically present (and often must 

22 negotiate the right to be so with the venue owner) or proxy their services through the 

23 venue owner and staff. 
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1 SUMMARY OF THE INVENTION 

2 The present invention provides a solution to the foregoing issues, as well as 

3 additional benefits, e.g., freeing consumers from carrying cash into venues, reducing 

4 transaction fees and financial risk for venues, and increasing branding opportunities for 

5 manufacturers, distributors and third-party marketers. 

6 Basic Purchasing System/Method 

7 The present invention discloses a system and method for enabling the remote 

8 purchasing of products (e.g., alcoholic beverages) wherein, as part of the buying 

9 transaction, the purchaser indicates a specific physical location ("venue") where the 

10 product will be picked up ("claimed"); may identify a third party as the "recipient" of the 

1 1 product by providing the third-party's e-mail or text messaging address (or another 

12 method of electronic contact); optionally can attach a personalized message (and various 

13 multimedia files such as photos and audio recordings) to the transaction; and optionally 

14 can specify the information required for recipients who are already known to the system 



15 to make an expedited return purchase using a feature known as "instant reciprocity," in 

1 6 real or near-real time. 

17 Purchasing Variants 

18 The present invention also enables other purchasing variants including, e.g., 

19 barhopping purchases in which a purchase includes multiple drinks at multiple venues; 

20 group purchases that enable purchasing for groups; group barhopping purchases; and a 

21 "hint-hint" feature that allows an end user to push a broadcast out to his/her friends (or 

22 other group of users). A broadcast contains a link (or other transactional pointer) that 

23 enables the broadcast recipients to quickly buy a drink for the broadcaster, and brand 
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1 purchases, wherein a venue or site is selected under the aegis of a larger brand such as a 

2 cruise line, hotel chain, restaurant chain, or chain of pubs. 

3 It is contemplated that a user can use a system consistent with the present 

4 invention to make a purchase for himself or herself, rather than for someone else. 

5 Alternatively, a single franchise, e.g., a coffee chain, might operate a system consistent 

6 with the invention as a single-brand remote purchasing engine. 

7 Venue Directory 

8 In addition, the present invention discloses related systems and methods that 



9 enable descriptive listing information on participating venues (such as venue address, 

10 items in stock and customer ratings) to be accumulated in a distributed fashion, whereby 

1 1 the system administrator can assign (distribute) responsibility for individual items in the 

12 listing to different users participating in the system, allowing them to individually 

13 provide, manage and update the majority of their own information by interacting with the 

14 system and without requiring human mediation; allowing potential purchasers ("end 

15 users") to look up via "pull" searching or receive via electronic "push" notification 

16 specific pieces of information associated with these venues; and, as needed, allowing the 

17 system administrator to manage the activities and content being supplied by other users.. 

18 Marketing 

19 Moreover, the present invention discloses related systems and methods that 

20 enable system users (dependent on user type and the parameters set by the system 

21 administrator) to engage in marketing activities directed at either/both end users and 

22 venues wherein, such activities include, e.g., generating "push" and "pull" marketing 

23 campaigns that target specific users or are activated by specific system-mediated events; 



6 



1 and generating statistics and/or data mining reports on users and their transactions with 

2 the system. Such efforts may be tailored to specific circumstances that take into account, 

3 among other things: demographics, locations, time, and device and platform information, 

4 wherein the providers of aforementioned marketing and advertising services operate as 

5 independent agents in purchasing, designing or using these services (but under the 

6 jurisdiction of the system administrator and system parameters), and wherein both end 

7 users and venues will have various "opt in" preferences that will modify the delivery of 

8 these marketing and advertising services to them as individuals. Some of these marketing 

9 activities may depend on the use of radio-frequency identification (RFID) or other short- 

10 range wireless communications technologies. Furthermore, some of these activities may 

1 1 generate data on users that is encoded in such a fashion that the new information can 

12 become the basis of future marketing activities (e.g. using response rate to a campaign, or 

13 answers to an encoded survey as "target" variables in a subsequent campaign). 

14 Location-Based Services 

15 Furthermore, this invention includes systems and methods that use RFID or other 

16 short-range sensing technologies that can read unique information stored in a chip, tag or 

17 card (a "token") carried by an end user to provide additional system functionality, 

18 including, e.g., expediting claim redemption by using this token in conjunction with a 

19 reader embedded in the venue claim terminal where the claim is being redeemed; using 

20 the token, in conjunction with a reader positioned somewhere in the venue (most likely in 

21 the doorway) and in conjunction with the networked nature of the venue claims terminals 

22 to create a location-based service in which authorized end users can view in real or near 

23 real time the whereabouts of other token-carrying users, and initiate a purchasing 
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1 transaction based on this information; using the token, in conjunction with a reader 

2 embedded in the electronic claim terminal at a venue in lieu of a traditional credit card to 

3 pay for goods. The tokens may be used for a wide variety of marketing activities, 

4 marketing to users based on their location at or near one or more venues. 

5 Friends List and Permissions 

6 Also, this invention includes methods for certain users to generate and manage 

7 lists of friends and groups of those friends, and a permissions-based system whereby a 

8 user can authorize friends or other users to view data associated with that user such as 

9 that user's instant reciprocity information or RFID location. 

10 Accounting 

1 1 The present invention further may handle transaction and account balance 

12 tracking such that they can be billed and reconciled either by the system or by passing 

13 this information to a third-party provider. 

14 BRIEF DESCRIPTION OF THE DRAWINGS 



15 Figure 1 is a process flow diagram illustrating an exemplary purchase in a system 

16 consistent with one embodiment of the invention; 

17 Figure la is a system architecture diagram of an exemplary remote purchasing 

1 8 system consistent with one embodiment of the present invention; 

19 Figure lb is a software architecture diagram illustrating an exemplary 

20 arrangement of modules in a system consistent with one embodiment of the present 

21 invention; 
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1 Figures 2a and 2b are collectively a process flow diagram outlining an exemplary 

2 sequence of steps performed by registered end users to make a purchase in an exemplary 

3 system consistent with one embodiment of the present invention; 

4 Figures 3a and 3b are collectively a process flow diagram outlining an exemplary 

5 sequence of steps performed by unregistered end users to make a purchase in an 

6 exemplary system consistent with one embodiment of the present invention; 

7 Figure 4 is a process flow diagram illustrating the transaction process for a fully 

8 connected device, including instant reciprocity functionality, in an exemplary system 

9 consistent with one embodiment of the present invention; 

10 Figure 5 is a process flow diagram illustrating the transaction process for a 

1 1 disconnected device, including instant reciprocity functionality, in an exemplary system 

1 2 consistent with one embodiment of the present invention; 

13 Figure 6 is a screen view of an exemplary screen for a registered user to make a 

14 purchase, in an exemplary system consistent with one embodiment of the present 

15 invention; 

16 Figure 7 is a screen view of an exemplary screen for an unregistered user to make 

17 a purchase, in an exemplary system consistent with one embodiment of the present 

18 invention; 

19 Figure 8 is a screen view of an exemplary claims notification message on a 

20 mobile telephone, in an exemplary system consistent with one embodiment of the present 

21 invention; 

22 Figures 9 and 10 are screen views of exemplary venue directory screens, in an 

23 exemplary system consistent with one embodiment of the present invention; 
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1 Figure 1 1 is a screen view of an exemplary screen for finding a venue, in an 

2 exemplary system consistent with one embodiment of the present invention; 

3 Figures 12 and 13 are screen views of exemplary screens for creating a survey, in 

4 an exemplary system consistent with one embodiment of the present invention; 

5 Figure 14 is a screen view of an exemplary survey preview screen, in an 

6 exemplary system consistent with one embodiment of the present invention; 

7 Figure 15 is a screen view of an exemplary reward creation screen, in an 

8 exemplary system consistent with one embodiment of the present invention; 

9 Figure 16 is a screen view of an exemplary push campaign creation screen, in an 

10 exemplary system consistent with one embodiment of the present invention; 

1 1 Figure 17 is a screen view of an exemplary target profile building screen, in an 

12 exemplary system consistent with one embodiment of the present invention; 

13 Figure 17a is a screen view of an exemplary campaign manager screen, in an 

14 exemplary system consistent with one embodiment of the present invention; 

15 Figure 17b is a system architecture diagram of an exemplary remote purchasing 

16 system incorporating RFID technology, consistent with one embodiment of the present 

17 invention; 

18 Figures 18 and 19 are exemplary screen views of administrator management 

19 screens, in an exemplary system consistent with one embodiment of the present 

20 invention; 

21 Figure 20 is a screen view of an exemplary system setup screen, in an exemplary 

22 system consistent with one embodiment of the present invention; 
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1 Figure 21 is a screen view of an exemplary user management screen, in an 

2 exemplary system consistent with one embodiment of the present invention; 

3 Figure 22 is a screen view of an exemplary system management screen, in an 

4 exemplary system consistent with one embodiment of the present invention; 

5 Figure 23 is a screen view of an exemplary login screen, in an exemplary system 

6 consistent with one embodiment of the present invention; 

7 Figure 23 a is a screen view of an exemplary legal drinking age certification 

8 screen, in an exemplary system consistent with one embodiment of the present invention; 

9 Figure 24 is a screen view of an exemplary profile submenu screen, in an 

10 exemplary system consistent with one embodiment of the present invention; 

1 1 Figure 25 is a screen view of an exemplary payment submenu screen, in an 

12 exemplary system consistent with one embodiment of the present invention; 

13 Figure 26 is a screen view of an exemplary transaction history screen, in an 

14 exemplary system consistent with one embodiment of the present invention; 

15 Figure 26a is a screen view of an exemplary venue world map plot screen, in an 

16 exemplary system consistent with one embodiment of the present invention; 

17 Figure 26b is a screen view of an exemplary venue regional map plot screen, in an 

1 8 exemplary system consistent with one embodiment of the present invention; 

19 Figure 26c is a screen view of an exemplary venue neighborhood map plot screen, 

20 in an exemplary system consistent with one embodiment of the present invention; 

2 1 Figure 27 is a screen view of an exemplary instant reciprocity settings screen, in 

22 an exemplary system consistent with one embodiment of the present invention; 
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1 Figure 27a is a screen view of an exemplary friends list setup screen, in an 

2 exemplary system consistent with one embodiment of the present invention; 

3 Figure 27b is a screen view of an exemplary friends/groups display screen, in an 

4 exemplary system consistent with one embodiment of the present invention; 

5 Figure 28 is a screen view of an exemplary event settings screen, in an exemplary 

6 system consistent with one embodiment of the present invention; 

7 Figure 28a is a screen view of an exemplary "hint-hint" setup screen, in an 

8 exemplary system consistent with one embodiment of the present invention; 

9 Figure 29 is a screen view of an exemplary events schedule display screen, in an 

10 exemplary system consistent with one embodiment of the present invention; 

1 1 Figure 30 is a screen view of an exemplary view friends list screen, in an 

12 exemplary system consistent with one embodiment of the present invention; 

13 Figure 3 1 is a screen view of an exemplary user registration screen, in an 

14 exemplary system consistent with one embodiment of the present invention; 

15 Figures 32 - 34b are screen views of exemplary registration and user information 

16 collection screens, in an exemplary system consistent with one embodiment of the 

17 present invention; 

18 Figure 35 is a screen view of an exemplary third-party marketer registration 

19 screen, in an exemplary system consistent with one embodiment of the present invention; 

20 Figure 36 is a screen view of an exemplary instant reciprocity message on a 

21 mobile telephone, in an exemplary system consistent with one embodiment of the present 

22 invention; and 
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1 Figure 37 is a screen view of an exemplary instant reciprocity user confirmation 

2 selection message on a mobile telephone, in an exemplary system consistent with one 

3 embodiment of the present invention. 

4 DETAILED DESCRIPTION OF THE EMBODIMENTS 

5 An exemplary implementation of a system consistent with the present invention is 

6 in the beverage (spirits) industry (including bars, restaurants, lounges, nightclubs and 

7 other commercial establishments that serve alcoholic beverages), enabling consumers to 

8 remotely purchase beverages for themselves or other individuals at participating locations 

9 (venues). The following discussion of this particular implementation of the system is 

10 meant to be illustrative of system capabilities and functionality but should not limit the 

1 1 application of a functionally identical, but rebranded system to other industry verticals 

12 with dispersed physical locations and different types of products. Such a system may be 

13 run under both an ASP and a self-host situation without any substantial modification. 

14 Further, the system may support operations in which venues are fully independent 

15 business entities participating as independent agents in the system or one in which venues 

16 are related under an umbrella brand (i.e., they are all franchisees of the same business). 

17 Exemplary Purchase Method 

18 Figure 1 illustrates the process flow 10 for an exemplary purchase in a system 

19 consistent with one embodiment of the invention. As shown, at block 12, the purchaser 

20 initiates the process by using a web or WAP browser to access the system and place an 

2 1 order for products to be redeemed later by the recipient at a given location. For example, 

22 the purchaser might be a friend wishing to purchase a beverage for the recipient at a 

23 selected bar. Next, at block 14, the system generates a claim for the order and transmits 

13 



1 electronic claims notification to both the recipient and the venue where the claim is to be 

2 redeemed. At block 16, the recipient comes to the venue to pick up the order, and an 

3 employee of the venue (e.g., a bartender) retrieves the order using a claims terminal, fills 

4 the order (i.e., serves the drink to the recipient), and enters an indication into the claims 

5 terminal that the order has been redeemed. At block 18, the claims terminal, which may 

6 be operating in a dial-up mode, periodically calls into the system to synchronize new and 

7 redeemed claims. 

8 Users 

9 The following table gives a broad overview of the various types of exemplary 
10 users that participate in the system and how they might interact with it: 

11 
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In the presently described embodiment, the end user web interface is the "main 
public face" of a remote purchasing system consistent with the invention. It is desirable 
that end users should first have to register with the system before being permitted to 
make purchases (e.g., so that the system can notify the purchaser if there is a problem 
with the order), although it is contemplated that in certain embodiments of the present 
invention, no registration would be required. It should be recognized that references 
made herein to unregistered and anonymous users are only applicable to embodiments of 
the invention wherein registration is not required in order for a user to perform or access 
certain system functions. 



16 



1 System Architecture 

2 Figure la provides a graphic overview of the system architecture of an exemplary 

3 remote purchasing system 100 consistent with the present invention. As shown, a 

4 plurality of clients 101 are connected, e.g., using HTTP and standard web browsers, to a 

5 system back end 102, with a webserver 103 acting as the core system. The clients 101 

6 may include, e.g., end users 104, venues 105, third-party marketers 106, members (not 

7 shown), and system administrators 107. The system back end 102 includes a database 

8 108 (e.g., accessible via SQL) and a plurality of modules 109 in communication with the 

9 webserver 103 (e.g., via API calls), which may include, e.g., payment processing 1 10, 

1 0 billing 111, messaging 121, and third-party plugins 122. 

1 1 The system 100 follows a common client-server setup supplemented by a 

12 powerful database 108. The primary client for all users 104-107 is an Internet web 

13 browser. The system may have the capability to support additional markup languages, 

14 such as WML for wireless devices via simple transforms. In addition, "fat client" 

15 implementations for emerging wireless device platforms may be implemented to provide 

16 end users to with a richer experience. In the case of such implementations, certain system 

17 resources shown in system 100 presently located on the server 103 will shift over to the 

18 client 101 side. In order to participate in the system, venues 105 run a specialized piece 

19 of client software on site that allows them to receive and process purchase claims in or 

20 near real-time. 

21 A number of third-party software modules 1 13 may be plugged into the backend 

22 102 via API calls or similar mechanisms to provide additional system functionality. Such 
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1 modules may include, e.g.: payment processing 1 10, billing/checkwriting 111, and 

2 messaging 112. 

3 The payment processing module 1 10 may accept and process an array of 

4 credit/debit cards and other types of accepted electronic currency, as described in further 

5 detail hereinbelow. The billing/checkwriting module 1 1 1 may generate physical 

6 bills/checks on the basis of internal system criteria, as described in further detail 

7 hereinbelow. It is also possible that a system consistent with the present invention might 

8 not include a payment processing 1 10 or billing/checkwriting 1 1 1 modules, in which case 

9 such functionality would be handled by one or more external systems. It should further 

10 be recognized that a system consistent with the present invention may include accounting 

1 1 functionality, whereby an account, "points", or credit balance is kept for each user, and 

12 wherein users must "recharge" their balance as necessary to have a sufficient balance to 

13 complete a purchase. However, it is contemplated that in certain embodiments of the 

14 present invention, purchases by users are made using credit or debit cards, or other 

15 payment methods, e.g., direct billing to a user's telephone bill, on a per-transaction basis. 

16 In this configuration, the system may store such payment information for each user, as 

17 may be appropriate, and it is not necessary that the system keep track of a "balance" for 

1 8 each user. It should be recognized that references made herein to "credits" and 

19 "balances" herein are only applicable to embodiments of the invention wherein the 

20 system stores an account balance for each user. 

21 A messaging module 1 12 responsible for all system messaging will support, e.g., 

22 email, SMS and MMS messaging. The principal purpose of the messaging client 1 12 will 



18 



1 be to deliver claims notifications to recipients, claims information to venues, and 

2 transaction confirmations to purchasers. 

3 In one embodiment, the software modules might be arranged as illustrated in 

4 Figure lb, wherein the modules include marketing, end-user operations, venue interface, 

5 member interface, third-party marketers, campaign manager administration, accounting 

6 administration, content administration, user administration, partner administration, and 

7 master system administration. The operation of each of the foregoing modules is 

8 described in further detail hereinbelow with reference to the individual system functions. 

9 The foregoing described system architectures and system modules are of one 

10 exemplary system consistent with the invention, and it is contemplated that other system 

1 1 architectures and modules may be used in various embodiments of the present invention. 

12 Remote Purchasing Description and Process 

1 3 The concept of remote purchasing as embodied in a system consistent with the 

14 present invention is distinctive for a number of reasons, including: it permits a purchase 

15 in which a particular physical location (or, e.g., a chain of stores) where a purchase may 

16 be claimed; the purchaser need not be physically present at the site where the purchase is 

17 made; the purchaser may designate another person as the recipient of the purchase using 

18 the recipient's messaging address as their identification; the recipient of a purchase picks 

19 up their product(s) in person; optionally, the purchaser can configure their account so that 

20 a recipient can buy something in return for the purchaser with a single click ("instant 

21 reciprocity"); and the system may be adapted to handle all of the notification and billing 

22 issues to support this functionality. 
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1 In the system implementation, a purchaser (end user) operating on a supported 

2 client first initiates the remote purchasing process, e.g., through one of a number of 

3 available entry points: 
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4 

5 Figures 2a and 2b are collectively a process flow diagram 200 outlining an 

6 exemplary sequence of steps performed by registered end users to make a purchase, and 

7 Figures 3a and 3b are collectively a process flow diagram 300 outlining an exemplary 

8 sequence of steps performed by unregistered end users to make a purchase. 

9 Figures 2 through 5, described hereinbelow, are flowcharts illustrating the 

10 architecture, functionality, and operation of one possible implementation of the present 

1 1 invention. In this regard, each block represents a module, segment, or portion of code, 

12 which comprises one or more executable instructions for implementing the specified 

20 



1 logical function(s). It should also be noted that in some alternative implementations, the 

2 functions noted in the blocks may occur out of the order shown in the Figures. For 

3 example, two blocks shown in succession may in fact be executed substantially 

4 concurrently, or the blocks may sometimes be executed in the reverse order, depending 

5 upon the functionality involved, and certain blocks may not always be employed. 

6 Moreover, it should be recognized that the order of the blocks may also vary depending 

7 on the circumstances and the point at which an end user initiates the purchasing process. 

8 As shown in the flowcharts of Figures 2a and 2b and the exemplary screen view 

9 600 of Figure 6, if the end user (i.e., the purchaser) is registered and logged in, the 

10 process begins at block 201 , and an initial determination is made at block 202 whether 

1 1 the purchaser has initiated the process from the transaction history page (discussed in 

12 further detail below). If not, the purchaser is prompted at block 203 whether to identify 

13 the intended recipient by name (may be the recipient himself) from a drop-down friends 

14 list. If the recipient is not on the drop-down list, the purchaser is prompted at block 206 

1 5 to input the name of the recipient, and the email address or cell phone number of the 

16 recipient at block 207 (other electronic contact methods may be used, e.g., a pager). A 

17 check box or other simple indication (not shown) may be provided to permit the 

1 8 purchaser to add a manually-entered recipient to his or her friends list. It should be noted 

19 that at least one electronic address or number (for email or wireless messaging) is 

20 required, and that a second address may further be specified. A determination is made at 

21 block 208 whether the purchaser initiated the buying process from a venue directory 

22 page. If not, the purchaser is prompted to enter the name of the venue at block 209. If 

23 so, the process continues at block 210. At block 2 1 0, the purchaser enters the products 
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1 and quantity of products to send to the recipient. At block 2 1 1 , a determination is made 

2 whether there is a sufficient credit balance to cover the purchase. If not, the user may 

3 purchase sufficient credits at block 212. If there is already a sufficient credit balance, the 

4 process continues at block 213. If, at block 203, the user is identifiable using the drop- 

5 down list, the purchaser is prompted to select the recipient from the list at block 204. 

6 Once the recipient is selected at block 204 from the drop-down list, a determination is 

7 made at block 205 whether there is a venue and/or product associated with the recipient. 

8 If, at block 205, it is determined that there is already a venue and/or product associated 

9 with the recipient, then the process continues at block 211. If not, the process continues 

10 at block 209, for the selection of a venue. At block 213, the purchaser may opt whether 

1 1 to send a message (and/or multimedia file) to the recipient. If not, the process continues 

12 at block 215. If so, the purchaser is prompted at block 214 to input the message. At 

13 block 215, the purchaser is prompted whether to schedule a delivery date and time 

14 (otherwise, the purchase will be immediate). If not, the process continues at block 217. 

15 If so, the purchaser is prompted at block 216 to input the date and time for the purchase 

16 to be sent. At block 2 1 7, the purchaser is prompted whether to make the purchase 

17 recurring (e.g., every x minutes, daily, weekly, annually). If not, the process continues at 

18 block 219. If so, the purchaser is prompted to set the recurrence frequency at block 218. 

19 At block 219, the purchaser is prompted to review and confirm the order, and the process 

20 ends at block 220. If, at block 202, it is determined that the process was initiated from 

21 the transaction history page, then the process continues at block 219, for review and 

22 confirmation of the order. It should be noted that, in the above process 200, if the 

23 purchaser is a registered end user and has activated instant reciprocity (as described in 
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1 further detail below) and the recipient's messaging address is recognized by the system, 

2 the purchaser's instant reciprocity information will be included for review. 

3 As shown in the exemplary flowcharts of Figures 3a and 3b and the exemplary 

4 screen view 700 of Figure 7, if the end user is unregistered, the process begins at block 

5 301 , and the user (i.e., the purchaser) is prompted at block 302 to input the name of the 

6 recipient (which may be the purchaser himself), and the email address or cell phone 

7 number of the recipient at block 303. It should be noted that at least one electronic 

8 address or number (for email or wireless messaging) is required, and that a second 

9 address may further be specified. A determination is made at block 304 whether the 

10 purchaser initiated the buying process from a venue directory page. If not, the purchaser 

1 1 is prompted to enter the name of the venue at block 305. If so, the process continues at 

12 block 306. At block 306, the purchaser enters the products and quantity of products to 

13 send to the recipient. A block (not shown) may be included to add a tip amount from the 

14 purchaser to be paid to the server of the products (e.g., a bartender). At block 307, the 

15 purchaser may opt whether to send a message (and/or multimedia file) to the recipient. If 

16 not, the process continues at block 309. If so, the purchaser is prompted at block 308 to 

17 input the message. At block 309, the purchaser is prompted whether he/she is also the 

1 8 recipient, in which case the process continues at block 311. If not, the purchaser is 

1 9 prompted at block 3 1 0 to enter the purchaser ' s name. At block 3 1 1 , the purchaser inputs 

20 payment type and details. A check box or other simple indication (not shown) may be 

21 provided to permit the purchaser to store his or her payment information for use in future 

22 transactions. An additional block (not shown) may be further provided to permit entry of 

23 a coupon or other discount code. At block 312, another determination is made whether 
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1 the purchaser is also the recipient, in which case, the process proceeds to block 314. If 

2 not, the purchaser is prompted to input the purchaser's notification address for 

3 confirmation at block 313. The process then continues at block 3 14 for the purchaser's 

4 review and confirmation of the order and ends at block 315. 

5 Successful completion of either of the above sequences 200, 300 will cause 

6 payment to be processed and various messages to be generated, e.g.: a confirmation 

7 message to the purchaser (if different from recipient), a claim notice to the recipient and a 

8 claim notice to the venue associated with the claim. In the case of an unregistered user 

9 making a purchase, there may be a delay on notification being sent to the recipient until 

10 the charge has successfully cleared. 

1 1 It should be recognized that appropriate functionality may be provided to permit a 

12 purchaser to "clone" an order, so that the identical order (or a slightly modified version 

13 thereof) may later be placed without the purchaser having to reenter all of the 

14 information. 

15 Prepopulation of Fields 

16 The system may be configured to streamline the buying process for an end user by 

17 prepopulating certain fields based on certain conditionals (These conditionals appear in 

18 the order in which they might be addressed by the system. It is contemplated that fields 

19 will only be prepopulated once, so if a field is already populated, it will not be 

20 overwritten by the prepopulation triggered by a later conditional.). Exemplary 

21 conditionals include: if the end user initiates the purchasing process from one of the items 

22 in their transaction history page, all fields will be prepopulated with the same values as 

23 the ones in the historical transaction; if the end user initiates the purchasing process from 
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1 a venue search results page, the venue field will be prepopulated with the selected venue 

2 (and possibly, the products field may be populated with a pre-selected product, as well, 

3 e.g., drink information); when identifying the intended recipient, registered end users 

4 who have created a friends list will be able to select from a drop down friends list, 

5 wherein if a friend is selected, a number of fields will be prepopulated with the friend's 

6 information (recipient name, recipient messaging address, and if there is information on 

7 the recipient's favorite venue and product, both of these fields); if the purchaser is a 

8 registered end user and has activated instant reciprocity and the recipient's messaging 

9 address is recognized by the system, the purchaser's instant reciprocity information will 

10 be included for review; if the purchaser is a registered end user and the total cost of the 

1 1 transaction is greater than said user's current account balance, the user will be prompted 

12 to buy more credits (e.g., they may have the option of selecting from a drop down list of 

13 previously saved payment options whose selection will prepopulate the payment fields 

14 and ask for a pin # as confirmation). 

15 Instant Reciprocity 

16 In certain embodiments, there is a special exception to the standard purchasing 

17 process flows 200, 300 described above, a feature referred to herein as "instant 

1 8 reciprocity". This feature enables the recipient of a claim to initiate an expedited 

19 reciprocal purchase to the original buyer (e.g., with a single keypress). It is contemplated 

20 that the instant reciprocity feature would only be available under the following 

2 1 conditions: both the recipient and original purchaser are registered users; the original 

22 purchaser has indicated their favorite drink and venue preference as part of their instant 

23 reciprocity settings; and the recipient account balance is greater than the price of the 
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1 original purchaser's favorite drink (or the recipient has previously stored payment 

2 information such as a credit card in the system). 

3 Figures 4 and 5 illustrate exemplary process flows for a instant reciprocity 

4 transaction in the cases of a fully connected (i.e., hardwired) and a disconnected device 

5 (i.e., capable of messaging), respectively. 

6 As shown in Figure 4, for a fully connected device, the transaction process begins 

7 at block 401 . The end user (in this case, the recipient, who will also be a purchaser for 

8 purposes of this transaction) receives and reads the message sent by the initial purchaser 

9 (who is about to become a recipient) at block 402 and is prompted at block 403 whether 

10 to return a drink with the instant reciprocity option (e.g., by toggling or clicking an option 

1 1 presented) bringing the transaction up for review, as illustrated in the exemplary screen 

12 view 3600 of Figure 36. If the user chooses not to execute the instant reciprocity option, 

13 the process ends at block 404. If the user chooses to execute the instant reciprocity 

14 option, then at block 405 the user is presented with the preselected venue and/or 

15 product(s) for approval, and if user selects the option that the return order presented to the 

16 user is satisfactory, the process continues at block 407. If the return order is not 

1 7 satisfactory, the user inputs a new venue and/or product(s) at block 406, which may be 

18 accomplished, e.g., by the user changing the quantity, product or venue by clicking a 

19 change option next to each item presented on the user's display. At block 407, the user is 

20 prompted whether to add a message, in which case the user inputs a message at block 

2 1 408. If the user chooses no to add a message, then the process continues at block 409. At 

22 block 409, the user confirms the transaction, and the process ends at block 410. 



26 



1 As shown in Figure 5, for a messaging-capable disconnected device, the 

2 transaction process begins at block 501 . The end user (in this case, the recipient, who 

3 will also be a purchaser for purposes of this transaction) receives and reads the message 

4 sent by the initial purchaser (who is about to become a recipient) at block 502, (as 

5 illustrated in the exemplary screen view 3600 of Figure 36. The user is then presented 

6 with a brief description of the instant reciprocity feature and is prompted at block 503 

7 whether to return a drink with the instant reciprocity option (e.g., by toggling or clicking 

8 an option presented in the message) bringing the transaction up for review. If the user 

9 chooses not to execute the instant reciprocity option, the process ends at block 504. If the 

10 user chooses to execute the instant reciprocity option, then at block 505 the user is 

1 1 prompted to reply to the instant reciprocity message. The user confirms the transaction 

12 (e.g., by entering the letter "Y" for "yes" in the body of the return text message, as 

13 illustrated in the exemplary screen view 3700 of Figure 37) at block 506, and the message 

14 is sent at block 507. The process ends at block 508. Alternatively, a URL, hyperlink, or 

1 5 other routine may be provided, whereby a single keypress or button click may be 

16 employed to activate an instance of instant reciprocity. 

17 Prepopulation functionality, as described hereinabove, may also be provided for 

1 8 instant reciprocity information. Additionally, if text messaging or email is used to 

19 activate instant reciprocity, one or more of the following conditions may need to be 

20 satisfied: (1) the recipient is a registered user; (2) the original purchaser has indicated a 

21 drink and venue preference as part of his instant reciprocity settings and the original 

22 recipient has permission to see this information; and (3) the recipient has stored payment 

23 information with the system. In this scenario, it should be recognized that the system 
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1 should desirably prompt the recipient to complete any data items still missing from the 

2 transaction (although, if all of the foregoing conditions are satisfied, then no items will be 

3 missing from the transaction and the order is ready for processing without further 

4 prompting by the system) and/or to change any prepopulated fields provided. 

5 It should further be noted that if the original recipient has also attended to his or 

6 her instant reciprocity settings, the foregoing described process can be iterated endlessly, 

7 enabling the pair involved in the transactions to send products (e.g., drinks) back and 

8 forth in a ping-pong fashion. This iterative behavior may be slightly modified when the 

9 RFID find-a-friend feature (described in further detail hereinbelow) is implemented as 

10 part of the system. In this scenario, if the original purchase transaction is initiated by 

1 1 finding a friend, when it comes time for the original purchaser to return an instant 

12 reciprocity received from the recipient, the initial purchase will be repeated until the 

13 RFID find-a-friend registers that the original recipient has left the venue in which he or 

14 she had been. 

15 Other Purchasing Variants 

16 In certain exemplary embodiments, e.g., special purchasing variants may be 

17 provided, as follows: 

18 For example, in a drink purchasing implementation, a "barhopping" feature may 

19 be provided, which would allow a purchaser to add additional venues and drinks to the 

20 basic purchase, thereby creating a barhopping itinerary. Additional functionality may be 

21 provided for making the itinerary random, wherein the next location is automatically 

22 randomly selected by the system, and a claim notification is sent out once the previous 

23 drink has been claimed. If the purchaser indicates that he or she wishes to set up a 
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1 barhopping purchase, the basic venue and drink selection process would cycle until the 

2 purchaser indicates that the itinerary is complete. 

3 As another example, a "group purchase" feature may be provided, e.g., for 

4 facilitating the purchase of drinks for a group of people at one venue. This may be 

5 achieved by using group information previously entered in the friends list, i.e., the 

6 purchaser can create groups similar to e-mail distribution lists. In this scenario, a special 

7 interface page would allow rapid assignment of drinks to individuals or for indicating that 

8 one menu selection should be given to all members of the group. The group purchase 

9 features may be combined with the barhopping features in a single transaction. 

10 A further example is a "hint-hint" feature, which would allow an end user to 

1 1 schedule and send out a broadcast message (e.g., to a group of friends) inviting recipients 

12 to buy him or her a particular drink at a particular venue. Acting on the hint-hint would 

13 involve a process similar to that of instant reciprocity for registered users, but otherwise 

14 might require an expedited registration, wherein an offer to fill out a longer marketing 

15 registration would be sent to these users at a later point) before recipients can complete 

16 the transaction. 

17 Still another example is a "brand purchase" feature, wherein a brand is any 

18 company that represents multiple venues, such as a chain of brewpubs, a line of cruise 

19 ships or a chain of hotels. An end user looking to make a purchase at one of these 

20 branded venues would be able to find any of these locations through the normal venue 

21 search, or alternatively, the end user would be able to click on a brand purchase icon, 

22 which would retrieve and display a list with all of the venues associated with the brand. 
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1 Once the user has made his venue selection, the purchase transaction would proceed 

2 normally. 

3 It is contemplated that a user might use a system consistent with the present 

4 invention to make a purchase for himself or herself, rather than for someone else, without 

5 requiring any additional functionality, simply by specifying the user's own email address, 

6 or phone number. Alternatively, a single franchise, e.g., a coffee chain, might operate a 

7 system consistent with the invention as a single-brand remote purchasing 

8 engine. Additionally, a virtual "shopping cart" or "basket" may be provided to permit a 

9 purchaser to arrange one or more purchases and thereafter provide payment information 

10 in a single instance, rather than having to do so for each individual product or service 

1 1 purchased. Such a shopping cart may further be configured to permit a plurality of 

12 products and/or services from a plurality of venues to be purchased in a single payment 

13 transaction. 

14 Claims Notification and Redemption 

1 5 A system consistent with the present invention may be configured such that a 

16 successfully completed remote purchasing transaction (as described hereinabove) 

17 generates a record in the system known as a claims record. Items associated with this 

18 record may include, e.g., the following data: claim number (set by system; next available 

19 claim record number), claim code (random multi-digit alphanumeric, numeric, or 

20 otherclaim ID used to claim the product), redemption venue ID (a pointer to the 

21 information about the venue where the product will be claimed), products information 

22 (information about the products to be claimed), purchaser ID (if they are a registered 

23 user, a pointer to the information about the sender, and if not, information describing the 
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1 purchaser collected during the purchasing process), a message, including attached files (if 

2 the purchaser provided them), recipient name and/or ID number (if a registered user, a 

3 pointer to the information about the recipient, and if not, the information describing the 

4 recipient collected during the purchasing process), date/time of completed transaction, 

5 date/time claimed (blank field indicates an open claim), and purchaser/recipient interface 

6 types (for data mining). 

7 The claims record may be used to build a number of different messages for 

8 delivery to various parties in the transaction. The messages may include, e.g.: a claims 

9 notification message (a message to the recipient that identifies what has been purchased 

10 to the recipient), the claim location (with all the information needed to claim the 

1 1 purchase), seek additional information or reply to the sender (as illustrated in the 

12 exemplary screen view 800 of Figure 8), purchaser confirmation message (if the 

13 purchaser is different from the recipient, a message confirming that the system has 

14 successfully processed and dispatched the claim, including updating the purchaser's 

15 transaction history to show this new record), and delivery of claim to venue (a record 

16 delivered to the venue claims processing software in real or near-real time with the claim 

17 information; this information is automatically updated in the list of open claims that need 

18 redemption. 

19 It is contemplated that, to claim the product(s), the recipient simply visits the 

20 venue to which the claim was attached and gives a member of the staff the claim code. 

2 1 The venue staff member checks the code against the record in venue claims software, 

22 provides the specified product(s) and selects the redeem option in the venue software to 

23 indicate that the claim has been processed (the venue client is described in further detail 
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1 hereinbelow). In the event that recipient has lost or misplaced the claim, the system is 

2 configured so as to permit the venue to identify the recipient even without the claim code 

3 (In certain embodiments, the claim record may contain the name of the recipient, so that a 

4 recipient can make a claim by showing appropriate identification). In addition, both the 

5 sender and recipient can interact with the system to "regenerate" the claim by supplying 

6 the messaging address of the recipient (the "unredeemed claims" tab in the user interface 

7 is described in further detail hereinbelow). Uncollected claims may remain open and 

8 active for the period of time (e.g., 90 days) set by, e.g., the system administrator. The 

9 system may be adapted to periodically review and close unredeemed claims that have 

10 exceeded the preset collection period. The system may further be configured to send a 

1 1 reminder notice a certain number of days before a claim is closed, in order to remind the 

1 2 recipient to pick up their outstanding claim. 

13 Venue Directory 

14 One of the distinctive features of a system consistent with the present invention is 

15 the way it builds up and manages information about the venues participating in the 

16 system. This may be done in a distributed fashion whereby different users are responsible 

17 for inputting, managing and updating their own information. Because the effort of 

18 collecting and maintaining information in the system is broadly distributed, it becomes 

19 possible to provide up-to the minute information on such items as daily events (e.g., live 

20 music or the day's drink specials). Furthermore, the distributed approach increases the 

2 1 likelihood that venue information is accurate and that errors are rectified efficiently. As 

22 well, by pushing work out to system agents, the administrator saves time and resources, 

23 and can grow the directory quickly and organically. 
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1 System users (primarily end users) are able to look up venue records both for 

2 information purposes and as part of the purchasing process (as discussed hereinabove). 

3 In one embodiment, the cluster of information about a venue that both describes it 

4 and is publicly accessible to all system users is called a listing. When a venue submits a 

5 registration to become a member of the system (described in further detail hereinbelow), 

6 a large part of this registration consists of items that will appear in the listing. The set of 

7 items that comprises a complete listing may be defined by the administrator (listing setup 

8 is further described hereinbelow). Some of these items may be preset and locked by (or 

9 under the auspices of) the administrator or consist of end user generated content which 

10 the venue will be unable to change. In general, however, it is contemplated that the venue 

1 1 would be responsible for the majority of items that appear in the listing. However, the 

12 listing may additionally include items generated by end users of the system, such as a 

13 rating (e.g., on a scale of 1-10; used to determine the top-rated or top 5% for each city), 

14 wherein such information should desirably be made non-changeable by the venue. 

15 It should be recognized that a listing should typically not become active (and be 

16 publicly available) until the system administrator approves the venue's initial registration. 

17 After this initial approval, a venue can access and change venue modifiable items at any 

18 time via the venue web interface (this process is described in further detail hereinbelow). 

19 As illustrated in the exemplary screen views 900, 1000 of Figures 9 and 10, items in the 

20 venue listing may include, e.g.: venue name, address, telephone, email (if any), nearest 

21 subway or bus stop (if any), website URL (if any), hours of operation, brief description, 

22 venue category information, products/pricing schedule (some may be preset and locked 

23 by administrator), daily event information (e.g., drink specials/happy hour, events 
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1 schedules), cover charge (if any), and admissions/other policies (21+ etc). Venue 

2 category information may be selected from lists preset by the administrator, and may 

3 include, e.g., type (club, bar, restaurant), typical patron type (frat boy, pretty girl), events 

4 types (live music, DJs), and awards (Michelin stars, reviews). It should be noted that, for 

5 certain fields, it may be desirable that only the system administrator be able to modify 

6 certain fields in the venue directory, e.g., the brief description of the venue. 

7 In a system consistent with the present invention, other system users (primarily 

8 end users) are able to look up venue records both for information purposes and as part of 

9 the purchasing process (as described hereinabove). The system supports both a string 

10 matching quick search, and more precise searching in which search strings are tied to a 

1 1 specific field in the venue listing (as shown in the exemplary screen view 1 100 of Figure 

12 1 1). As well, several views of the search results may be available, e.g.: alphabetical, by 

13 user rating, showing live events (if any) and showing specials (if any). Some of the fields 

14 associated with a venue may comprise user-generated content, e.g.: overall rating and the 

15 number of raters. 

16 In an alternative embodiment, a system consistent with the present invention 

17 employing a distributed directory system may be used as a discount purchasing system. 

18 In this scenario, because each venue has distributed control over its own listing, including 

19 products/services being offered, the system could be used by individual stores as a means 

20 for moving excess inventory. 

21 Additionally, multiple language support may be provided as an additional feature 

22 of these listings, as well as of any other portion of the system. 
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1 Marketing Campaigns 

2 A system consistent with the present invention may include marketing campaign 

3 functionality that enables system users (dependent on user type and the parameters set by 

4 the system administrator) to engage in a wide variety of marketing activities directed at 

5 either/both end users and venues. Such activities include, e.g., generating "push" and 

6 "pull" marketing campaigns that target specific users or are activated by specific system- 

7 mediated event, and generating statistics or data mining reports on users and their 

8 transactions with the system, wherein such efforts may be tailored to specific 

9 circumstances that take into account factors such as demographics, locations, time, and 

10 device and platform information. The providers of such marketing and advertising 

1 1 services may operate as independent agents in purchasing, designing or using these 

12 services (e.g., as "Third-Party Marketers") and under the jurisdiction of the system 

13 administrator and various system parameters, including, for both end users and venues, 

14 "opt in" preferences that will modify the individual delivery of these marketing and 

15 advertising services to them. It should be recognized that all marketing and advertising 

16 activities in a system consistent with the present invention may be achieved via 

17 "marketing campaigns," i.e., marketing actions (or series of actions) undertaken by a 

18 system user and directed at end users and/or venues in the system. Additionally, a variety 

19 of statistical and data mining activities may be performed based on data accumulated 

20 through the use of marketing campaigns, as will be explained in further detail 

21 hereinbelow. 

22 In an exemplary embodiment, campaigns are defined by three primary traits: (1) 

23 WHO, i.e., the target of the action(s); WHEN, i.e., when the action(s) will start and how 
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1 long it will last; and (3) WHAT. Through the selection of a series of functional campaign 

2 blocks from among a set of available functional campaign blocks, the campaign creator 

3 builds a precise definition of the marketing action(s), including inputs and outputs. The 

4 concept of functional campaign blocks, as contemplated by the present invention, is best 

5 compared to the use of objects in object-oriented programming, wherein each of the 

6 functional campaign blocks, like objects, has a state and a set of operations to transform 

7 the state. A plurality of functional campaign blocks may be instantiated and concatenated 

8 to create a marketing campaign, as described hereinbelow. Alternatively, instead of 

9 using functional campaign blocks to construct a campaign, the campaign creator may 

10 have the opportunity to (or may be forced to) choose the campaign type from a list of pre- 

1 1 built campaign templates (e.g., provided by the system administrator). 

12 Campaigns may be performed by many types of users, e.g., the system 

13 administrator, members (the companies providing products to venues, e.g., alcohol 

14 companies), venues (e.g., bars), and third-party marketers (other brands). Though the 

15 actions undertaken by these different types of users will be similar, several operational 

16 differences may exist . For example, only the system administrator should be able to 

17 view raw user data, and all other groups should instead see category totals or summary 

18 data. The system administrator should be able to view and modify all user campaigns 

19 using a "campaign manager" module that permits the administrator to view campaigns, 

20 e.g., by user and launch date, in addition to other views. Other user types should have 

21 their registrations approved by the system administrator before they are permitted by the 

22 system to perform marketing activities. Of course, different users will have different 

23 restrictions/pricing schedules on their marketing activities. 
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1 As the exemplary screen view 1710 of Figure 17a illustrates, the campaign 

2 manager may be embodied as a graphical "digital dashboard" through which system 

3 agents can view, search and edit campaigns, as well as create and schedule new 

4 campaigns. A campaign may be created from scratch using functional campaign blocks, 

5 by specifying the three primary traits: identify WHO the campaign will be directed at, 

6 define WHEN the campaign or campaign elements will launch and be in effect; and 

7 construct the WHAT of the campaign. In the exemplary screen view 1710, the campaign 

8 creator has already set the WHO and WHEN blocks of the campaign and is now working 

9 on detailing a WHAT block (circled): 

10 In order to simplify and automate the process of defining the WHO, WHEN and 

1 1 WHAT of a campaign, the system may provide campaign creators with a series of 

12 functional campaign blocks which can be mixed and matched to create an endless variety 

13 of campaigns. An exemplary set of functional campaign blocks is provided in the 

14 following table: 



WHO 


WHEN 


WHAT 


External Initiation 
(Special registration check) 


One-time 


1-Way Broadcast (this block 
can act as an "end codon" to a 
campaign) 


Internal Initiation via Profile 
Construction 
(Variants: In response to 
campaigns, subgroups) 


Ongoing 


2- Way Broadcast 
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Internal Initiation via End User 
Event 


Repeat at Intervals 


Encoded Form 


Internal Initiation via Specific 
Users (Administrator only) 


Date Range 


Coupon for use during 
purchase (this block can act as 
an "end codon" to a 
campaign) 




Phased Date Range 


Coupon for redemption at 
venue (this block can act as an 
"end codon" to a campaign) 



1 

2 The WHO blocks indicate not only the targeted user but also who/what is 

3 responsible for first contact with those users. The WHO blocks may include external 

4 initiation, internal initiation via profile construction, internal initiation via end user event, 

5 and internal initiation via specific users. 

6 In the case of external initiation, the agent conducting the campaign will make 

7 first contact with the targeted users via their own external channels. For example, a 

8 company might have a list of 200,000 SMS numbers and will broadcast a teaser message 

9 to those users that contains a link to an encoded form (see WHAT blocks hereinbelow) in 

10 the system. Because respondents to externally initiated campaigns may not yet be 

1 1 registered users of the system, externally initiated campaigns should have a unique entry 

12 URL where the respondent will be asked if they are already a system user. If not, they 

13 may need to fill out a short form registration before continuing on with the campaign. 



38 



1 In the case of internal initiation via profile construction, the agent builds a profile 

2 of the users who will be targeted for the campaign. The items available for selection as 

3 variables in the profile include items about users gathered during registration (such as sex 

4 and home city), items accumulated as a result of user activities (e.g., users who have 

5 made a transaction within the last 30 days, or users who have made a transaction at a 

6 particular venue X) and items accumulated as a result of previous campaigns (e.g., new 

7 variables about taste in watches captured by an encoded marketing form (see WHAT 

8 blocks below), or respondents to a previous campaign x). This last source of items for 

9 profiles has two special considerations for agents building new campaigns: first, as part 

10 of the profile, the agent will be able to select targets of a previous campaign at the level 

1 1 of respondents/non-respondents to the earlier campaign; and second, an agent may be 

12 allowed to divide the target population in subgroups so that different campaign texts or 

13 styles can be tested against one another for effectiveness. The agent may be able to make 

14 divisions based on random assortment or building sub-profiles. When a subgroup is 

15 created, the campaign elements are copied in and can then be filled out in parallel. A 

16 target profile may be constructed by using a dashboard-like interface in which profile 

17 categories (the data variables) are dynamically derived from the table labels in the system 

18 database. Exemplary table labels may include: city of residence, age, gender, primary 

19 messaging type, last transaction date, preferred brand of watch, respondents to prior 

20 campaign A, and nonrespondents to prior campaign A. Target profiles may be 

21 constructed in a two-step process: first, the agent selects a variable of interest (such as 

22 gender) to add to the profile; and second, the agent indicates the desired value(s) of that 

23 variable (e.g., male). For fully encoded items this choice may be presented as a pull-down 
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1 list), and for numeric or string items, it may be an input field of the appropriate type and 

2 may include recognition of conditionals such as: >, =, <, and, or, includes. An agent 

3 may be able to select multiple variants of an encoded item that includes more than two 

4 choices. The foregoing two-step process is repeated until the profile is complete. 

5 In the case of internal initiation via end user event, this kind of campaign is 

6 selected to reward or provide an incentive to end users for performing certain kinds of 

7 actions in the system. Several exemplary types of events may be chosen from upon 

8 selection of this option: activated registration (when a user has both registered and made 

9 at least one valid transaction); marketing registration (when a user completes his or her 

10 opt-in marketing registration, this can initiate a campaign that rewards him or her for 

1 1 this); transaction (transactions encapsulate goods, recipients and venues, and an agent 

12 creating a campaign specifies which transaction types and the number of times an end 

13 user should engage in that transaction type to initiate the campaign; this may be one way 

14 a company might perform a "buy 4, get the 5th free" campaign, or, the agent could create 

15 a campaign to reward people who make city-to-city transactions, etc.); and RFID 

16 proximity event (occurs when an end user carrying an activated RFID card enters or exits 

17 a venue (described in further detail hereinbelow). 

18 In the case of internal initiation via specific users, the administrator (but desirably 

19 not other types of system users) can select specific users for a campaign. 

20 The WHEN blocks indicate when the campaign will run, and the system logic 

21 desirably ensures that the selected WHEN is compatible with the WHAT of the 

22 campaign, the WHEN blocks may include: one-time (a one-off campaign, usually a 

23 message, and associated with a single date); repeated at intervals (when a one-time 
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1 campaign will be repeated, wherein in addition to the start date, a repeat interval is 

2 specified in days); ongoing (campaigns that run continuously, associated with a start 

3 date); date range (campaigns that will run for a period of time, then end, associated with a 

4 start date and an end date); and phased date range (campaigns that will run in phases, and 

5 include start dates and end dates for each round of the campaign). 

6 The WHAT blocks are used to build the core of the campaign and are similar to 

7 objects in object-oriented programming languages in that each WHAT block is 

8 "described" by variables whose values change in different "instances" of the block. The 

9 WHAT blocks may include 1-way broadcast, 2-way broadcast, encoded form, "use 

10 during purchases" coupon, and "redeem at venue" coupon. 

1 1 For a 1-way broadcast, a message is sent to an end user that has no reply-to 

12 address, using, e.g., e-mail, MMS and/or SMS message types. 

13 A 2-way broadcast is similar to a 1-way broadcast, except that this block includes 

14 variables defining where the response will go and how it will be processed. 

15 An encoded form is a form accessed via a unique URL that the system provides. 

16 The encoding should be used to dynamically create new tables in the database that will 

17 enrich the information associated with various users. The encoding process may be 

18 expanded to include error-checking parameters associated with each form item. The 

19 form may include the following exemplary fields: general information (e.g., form title, 

20 which can be used as the database table label; co-sponsor logo; and number of questions) 

21 and information per question (e.g., question label, which may be used as the table 

22 column label; text of question; and answer encoding type with accompanying text, such 

23 as single answer-number, single answer-text string, and encoded list providing number of 



41 



items and item labels). Exemplary screens for designing a survey 1200, 1300 are 
illustrated in Figures 12 and 13, and fields specified may include both general 
information and information per question. General information might include, e.g.: 
survey title (can be used as database table label), date survey goes out, date survey will be 
closed, rewards points (per question or for the survey as a whole), target specific user 
profile (otherwise survey will go to all users who have opted in), survey text (to go in the 
email asking the end user to respond), number of prizes (0 if none; any other value causes 
the system to select this number of end users who have completed the survey as winners); 
and cosponsor logo. Information per question might include, e.g.: question label (used as 
table column label), text of question, and answer encoding type (e.g., single answer- 
number, single answer-text string, and encoded list (provide number of items and item 
labels). By providing the foregoing information, the survey text may automatically be 
flowed into the encoded form design template and can be assigned its own unique URL, 
and an end user might see the survey as shown in the exemplary screen view 1400 of 
Figure 14. Because of the tight encoding associated with surveys, each survey can be 
described as a new data table (or the extension of an existing data table) in the database. 
This new table will be dynamically linked to the existing user profile tables in order to 
expand the number of fields associated with each user. In addition, new table column 
headings may become available in the list of parameters used in future profile 
construction and data searching/mining/analysis operations (described in further detail 
hereinbelow). 

A "use during purchase" coupon is an electronic message similar to a claim 
notification that has a unique coupon ID. It may represent a discount, e.g., of 10-100% 
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1 off of some type of product and may be associated with a specific product and/or venue, 

2 though it need not be, e.g., in the case of external coupons. Coupons are not automatically 

3 applied, but are entered during a purchase transaction. This code can be checked to 

4 ensure that it has not been used yet, and that it fulfills the associated (if any) conditions 

5 for the items it represents. The discount then applied to a purchase price will be billed 

6 instead to the coupon issuer. Coupons are good for a time period set during coupon 

7 creation, e.g., 90 days. In addition, at the time of creation it can be specified whether a 

8 coupon can be used in the case where the recipient is also the purchaser. The number of 

9 coupons to issue can also be specified. 

10 A "redeem at venue" coupon is a coupon for a non-system product (for example, 

1 1 a new alcoholic drink that is being promoted). Venue terminals may support the 

12 redemption of these coupons, which may include variables defining the venues at which 

13 the coupon will be accepted. 

14 A wide variety of marketing activities are all attainable by combining functional 

1 5 blocks. The invention should not be construed as limited to the foregoing functional 

16 block descriptions, and it should be understood that new activities not specifically 

17 mentioned herein may simply be enabled by adding additional functional blocks to the set 

1 8 of those discussed hereinabove. 

19 The system may alternatively or additionally be configured such that a user 

20 creating a marketing campaign provides information to the system by following a series 

2 1 of prompts or using pre-built campaign templates provided by the administrator, whereby 

22 the system determines the appropriate selection of functional blocks and automatically 

23 creates the marketing campaign. For example, information for which the campaign 
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1 creator might be prompted to create an exemplary "push" campaign (as illustrated in the 

2 pre-built templates of the exemplary screen views 1600, 1700 of Figures 16 and 17) 

3 might include: campaign name (internal name for the campaign), target parameters (sets 

4 the parameters describing the target recipients), get estimate (provides estimate of the 

5 cost of campaign based on current statistics; result may vary from the estimate, especially 

6 in the case of a time differential between campaign creation and launch), set campaign 

7 cap (caps the price spent on campaign), set delivery date, set ongoing/one-time (if 

8 ongoing will set schedule of frequency), campaign type (plain text or html 

9 email/messaging, or both), campaign category — coupon or message, campaign text 

10 (fields for designing the campaign; these obey the limits, such as number of text 

1 1 characters, for the type selected above; a designer is able to cut and paste HTML and 

12 graphics into an HTML email text field), show preview (shows preview of campaign, 

13 including administrative wrapper that goes around all items), and how the campaign 

14 results will be processed. With regard to the method of processing the campaign results, 

1 5 the system may support the following exemplary options: set return address for response 

16 (can be URL), and no return address (response information included in message body as 

1 7 link or other). The system then takes all of the entered information, determines the 

18 appropriate functional blocks and values, and creates an appropriate campaign 

19 comprising of a set of functional blocks. For example, a template might be permitted for 

20 a venue to "push message (event notification) to recent patrons (last 30 days)". In this 

21 scenario, the template would automatically set the WHO to internal initiation via profile 

22 construction, selecting those patrons who have redeemed a claim at the venue in the last 

23 30 days. The WHEN would automatically be set to one-time, but might still prompt for 
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1 the date the message goes out. The WHAT block would automatically be set to 1-way 

2 broadcast. It should be noted that, although the template may automatically make block 

3 selections and preset some of the values for variables associated with the blocks, other 

4 items, such as the message text, may still need to be filled out by the agent selecting the 

5 template. 

6 Another example of a marketing campaign might be a reward point program that 

7 allows participating end users to accumulate reward points which can be redeemed for 

8 various rewards may be created using "internal initiation via end user event" as the WHO 

9 block and "ongoing event" as the WHEN block, combined with a WHAT functional 

10 block designed to handle accumulation of reward points and, e.g., transmission of point 

1 1 balances and available rewards to an end user. In such a program, exemplary events 

12 triggering accumulation of points might include an end user completing a purchase 

13 transaction, a new end user registering, and completion of an opt-in marketing survey. It 

14 is contemplated that venues, third-party marketers and/or the administrator could all list 

15 rewards in the system, and for venues and third-party marketers, it may be desirable to 

16 have a monthly fee associated with posting a reward. The system may be configured to 

17 permit a venue or third-party marketer creating a reward to supply information such as 

18 that shown in the exemplary screen view 1500 of Figure 15, and the system may use that 

19 information to select the appropriate functional blocks for constructing the campaign 

20 (rather than the venue or third-party marketer having to do so). As shown in Figure 15, 

21 such exemplary information might include: program name (internal name for reward), 

22 reward name (name of the reward as it will appear in the rewards listings), reward 

23 description (description of the reward as it will appear in the listings), reward offered by 
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1 whom, reward offered by logo (can be uploaded), reward first posting date (if the 

2 administrator is approving rewards, it is desirable for this date to be at least a week in 

3 advance of the present date), reward closing date, category class (from encoded list set by 

4 administrator), company class (from encoded list set by administrator), points to redeem 

5 the reward, and how the reward will be serviced. With regard to how the reward will be 

6 serviced, the system may support the following exemplary options: (1) to treat the reward 

7 points as a special transaction credit to the user and debit to the party offering the reward, 

8 wherein that credit can be bounded to a venue or an administrator "locked" product; (2) 

9 to connect the user to an external URL for redemption, wherein the end user's transaction 

10 ID can be forwarded to this URL and the system can support validation querying through 

1 1 an XML/SOAP API or similar protocol; in this case the party offering the reward will be 

12 responsible for reward redemption; or (3) send the user a reward coupon to their preset 

13 messaging address (it is desirable that this information NOT be passed on to the venue or 

14 third-party marketer), wherein each coupon has a unique ID associated with it, and the 

15 agent providing the reward may access/print an alphabetized list of IDs through its 

1 6 respective interface. 

17 A further example of a marketing campaign might involve a "buy n get nth free" 

18 feature, which could be used by a brewing company to promote its beer by giving a user 

19 the 5 th beer at no cost after buying four beers. In this case, the WHO would be internal 

20 initiation via end-user event, wherein the transaction is associated with the particular 

21 brand of beer. The WHEN might be ongoing. The WHAT would be a single block, i.e., 

22 the "use for purchase" coupon set at 100% discount and associated with the 

23 corresponding brand of beer. 
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1 Data Mining, Searching and Statistical Analysis 

2 It should be understood that campaign-based marketing activities, as described 

3 hereinabove, are desirably used to generate, augment and enrich stored data regarding the 

4 users of the system, to permit such data to be used for a wide variety of marketing 

5 purposes (i.e., that further generate and augment user data), thereby creating a feedback 

6 loop. Such data may be accumulated both via event-mediated activities of users, e.g., 

7 purchase history, or entrance into a venue (see RFID discussion hereinbelow) and via 

8 profile building activities, e.g., a user's profile data or answers to surveys. 

9 A system consistent with the invention may support three exemplary main types 

10 of data mining, searching and statistics functionality: (1) data searching (or mining) that 

1 1 identifies a subset of users based upon search criteria set by the user (as used, e.g., in 

12 creating a marketing campaign, as described hereinabove), (2) descriptive and 

13 comparative statistical analysis (including graphical representations) of system data, and 

14 (3) predictive analysis and mining of system data to identify undiscovered relationships 

1 5 and perform basic forecasting. 

16 It is contemplated that a system consistent with the invention may accumulate 

17 three types of interrelated raw data for storage in one or more databases. This data 

1 8 includes user data (descriptive data directly associated with a user of some kind, e.g., 

19 registration information on users, and venue listings information); transaction data 

20 (records associated with transactions, which records are linked with user data through the 

2 1 users and venues that participate in each transaction); and campaign data (a specialized 

22 form of user data including which users were contacted or participated in various 
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1 campaigns, and for campaigns using encoded forms, the new user data associated with 

2 that form). 

3 In addition to the user data collected on registration and through transactions, the 

4 database schema may include various internal data sets associated with users in order to 

5 facilitate the data mining process. Such variables may include, e.g.: for end users, date of 

6 registration, date of most recent activity, total transactions initiated, total transactions 

7 received, date of last marketing activity received, and date of last marketing activity 

8 responded to; for venues, date of registration, date of most recent system activity, date of 

9 most recent transaction, and total transactions processed; and for members and/or third- 

10 party marketers, date of registration, date of most recent system activity, date of most 

1 1 recent transaction, and total transactions processed. 

1 2 Data searching (or mining) that identifies a subset of users based upon certain 

13 search criteria: In its simplest form, the identification of a subset of users based upon 

14 search criteria is not really data mining at all as much as a search of database records. An 

15 element of mining does, however, enter into more complex searches, where the agent 

16 performing the search may choose to treat the search criteria as a "profile" that will serve 

17 as the basis for including/excluding records using data mining techniques. Data searching 

18 may take place under two exemplary circumstances, depending on the end user: In the 

19 first case, a venue, third-party marketer or administrator wishes to engage in a marketing 

20 campaign, as described hereinabove. In the second case, the administrator wishes to 

21 isolate a subset of the data for analysis. The architecture may support the export of this 

22 data as either an ASCII,tab-delimited file (or other common data file type) . In both 

23 cases, the agent performing the search will construct a "target profile" by selecting from 
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1 any of the data variables (labels) in the system. The list of variables might include the 

2 following exemplary data: venue location (geographic data, e.g., town/city), purchaser 

3 demographics (e.g., age, primary messaging type), recipient demographics (e.g., 

4 language, sex), and transaction information (including time/chronographic data, e.g., time 

5 sent, redemption time). Target profiles may be built in a two-step process (which may be 

6 done, e.g., using the campaign manager): First, the agent will select a variable of interest 

7 (such as gender) to add to the profile. Then, the agent will indicate the desired value of 

8 that variable (such as male). For fully encoded items this choice will be presented as a 

9 pull-down list; for numeric or string items, it will be an input field of the appropriate type 

10 but will also recognize conditionals such as: >, =, <, and, or, includes. 

1 1 Descriptive and Comparative Statistical Analysis: Once a data set has been 

12 isolated, the system may support the generation of descriptive and comparative statistics 

13 (especially graphical representations) on the basis of this data. Such analysis may take 

14 place under three exemplary main circumstances: (1) venues, third-party marketers and 

15 the administrator planning a marketing campaign are able to view summary statistics 

16 showing the total number and percent of records that matched the search profile, as well 

17 as the number and percent of records matching each of the search items; (2) venues, and 

18 third-party marketers are able to examine a fixed set of summary statistics regarding their 

19 own transactions (such as claims transactions or the results of an advertising campaign) 

20 in the system, and may be able to compare those results against an average baseline; and 

21 (3) the administrator is able to perform direct statistical analysis of the data or a selected 

22 subset of the data. This functionality may include, e.g.: univariate and multivariate 

23 correlation analysis; graphing of univariate/multivariate data including distribution of Y 
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1 and time series plots; fit Y by X modeling; multivariate fit modeling (regression and 

2 nonlinear analysis); and time series analysis, including forecasting models. 

3 Predictive Analysis and Mining of Data: The system may also support predictive 

4 analysis and mining. Some of the following exemplary data mining techniques may be 

5 supported: dependency detection and prediction techniques (identifying relationships, 

6 especially dependent ones, from among the data), classification and clustering (isolating 

7 distinct segments and groups from the data on the basis of driving variables), market 

8 basket analysis (processing transactional data in order to find those groups of products 

9 that are sold together well; one also may search for directed association rules identifying 

10 the best product to be offered with a current selection of purchased products; and 

1 1 deviation detection (a task of determining the most significant changes in some key 

12 measures of data from previous or expected values). This type of analysis may take place 

1 3 under the following exemplary circumstances: by the administrator to better identify 

14 trends and patterns in the data as well as to make forecasts about transactions; and to 

15 generate recommendations of various kinds (e.g., to end users as a "recommend one" 

16 feature to help locate venues they would like based on their profile; to venues to 

17 recommend the number/type/price of products to include for sale through the system; or 

18 to users engaged in marketing activities to suggest potential targets for a greater chance 

19 of success). 

20 Alternatively or additionally, further export functionality may be provided, to permit 

21 certain users (e.g., the system administrator) with functionality related to viewing, 

22 isolating, analyzing and exporting specific sections of data for mining or analysis in 

23 other, e.g., statistical, software packages. This functionality may include providing 
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1 various users with pretabulated (and/or graphed) statistics, dynamically using column 

2 labels for use in marketing campaigns initiated via profile construction, allowing the 

3 system administrator to search, view and export a subset of data via a similar process of 

4 profile construction (e.g., as ASCII or tab-delimited files), and allowing the system 

5 administrator to view items in the database directly. 

6 RFID Location-Based Services 

7 Radio frequency identification (RFID) systems represent a relatively new, non- 

8 line of sight alternative to traditional identification systems, e.g., barcode and barcode 

9 reader systems. A basic RFID system comprises three components: an antenna or coil, a 

10 transceiver (with decoder), and a transponder (RF tag) or other "token" electronically 

1 1 programmed with unique identification information. The antenna emits radio signals to 

12 activate the tag and read and write data to it. Antennas are the conduits between the tag 

13 and the transceiver, which controls the system's data acquisition and communication. 

14 Since antennas are available in a variety of shapes and sizes; they can even be built into a 

15 doorframe to receive tag data from persons or items passing through the door. If constant 

16 interrogation is not required, the field can be activated by a sensor device. Often the 

17 antenna is packaged with the transceiver and decoder to become a reader (a.k.a. 

18 interrogator), which can be configured either as a handheld or a fixed-mount device. The 

19 reader emits radio waves in ranges of anywhere from one inch to 100 feet or more, 

20 depending upon its power output and the radio frequency used. 

21 When an RFID tag passes through the electromagnetic zone, it detects the 

22 reader's activation signal. The reader decodes the data encoded in the tag's integrated 

23 circuit (silicon chip) and the data is passed to the host computer for processing. RFID 
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1 tags come in a wide variety of shapes and sizes. Animal tracking tags, inserted beneath 

2 the skin, can be as small as a pencil lead in diameter and one-half inch in length. The tags 

3 are categorized as either active or passive. Active RFID tags are powered by an internal 

4 battery and are typically read/write. Passive RFID tags operate without a separate 

5 external power source and obtain operating power generated from the reader. Passive tags 

6 are consequently much lighter than active tags, less expensive, and offer a virtually 

7 unlimited operational lifetime, although they have shorter read ranges than active tags 

8 and require a higher-powered reader. Read-only tags are typically passive and are 

9 programmed with a unique set of data (usually 32 to 128 bits) that cannot be modified. 

10 Read-only tags most often operate as a license plate into a database, in the same way as 

1 1 linear barcodes reference a database containing modifiable product-specific information. 

12 RFID systems are also distinguished by their frequency ranges. Low-frequency 

13 (30 KHz to 500 KHz) systems have short reading ranges and lower system costs. They 

14 are most commonly used in security access, asset tracking, and animal identification 

15 applications. High-frequency (850 MHz to 950 MHz and 2.4 GHz to 2.5 GHz) systems, 

16 offering long read ranges (greater than 90 feet) and high reading speeds, are used for such 

17 applications as railroad car tracking and automated toll collection. However, the higher 

18 performance of high-frequency RFID systems incurs higher system costs. 

19 The significant advantage of all types of RFID systems is the noncontact, non- 
20 line-of-sight nature of the technology. Tags can be read through a variety of substances 

21 such as snow, fog, ice, paint, crusted grime, and other visually and environmentally 

22 challenging conditions, where barcodes or other optically or magnetically read 

23 technologies might be useless. RFID tags can also be read in challenging circumstances 
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1 at remarkable speeds, in most cases responding in less than 100 milliseconds. The 

2 read/write capability of an active RFID system is also a significant advantage in 

3 interactive applications such as work-in-process or maintenance tracking. Though it is a 

4 costlier technology (compared with barcode), RFID has become indispensable for a wide 

5 range of automated data collection and identification applications that would not be 

6 possible otherwise. 

7 As implemented in a system consistent with the present invention, RFID 

8 technology may be used, e.g., to expedite claims processing, provide a location-based 

9 service (i.e., "find a friend"), and to permit an RFID card to be used as a credit card. 

10 Figure 17b illustrates an exemplary system 1720 for RFID implementation for a 

1 1 single venue, in one embodiment of the present invention. As shown, the system 

12 includes a venue claims terminal 1726 (described in further detail hereinbelow) and a 

13 remotely located RFID reader 1723 having an antenna 1722. Bluetooth interfaces 1724, 

14 1725 are provided for both the venue claims terminal 1726 and RFID reader 1723, so that 

15 these devices can wirelessly communicate with one another. The RFID reader 1723 

16 and/or antenna 1722 may be placed near a doorway at the venue, so as to capture the 

17 comings and goings of end users carrying RFID cards 1721 . In this scenario, after 

18 reading the cards 1721 of people coming in and going out, the RFID reader 1723 then 

19 transmits that information to the venue claims terminal 1726, e.g., using a Bluetooth 

20 connection. The venue claims terminal 1726 in turn can then upload or download this 

21 information to the central system (not shown), as needed. It is contemplated that an 

22 additional RFID reader 1728 and antenna 1727 having an extremely short range may 

23 further be supplied to the venue claims terminal 1726, e.g., to permit a patron to hand his 
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1 or her RFID card to the bartender, who can wave it in front of the additional RFID reader 

2 1728 to retrieve the patron's claim or to charge to the patron's card by using it as a proxy 

3 for his or her stored credit card or other payment method. Passive RFID cards 1721 

4 would need to be distributed to end users , which may be facilitated, e.g., through various 

5 promotions, such that the RFID card 1721 acts as a token that identifies the user to the 

6 system. The user may have to enter a number printed on the card to "activate" it and/or 

7 specify user preferences (e.g., whether the user wants the card to be useable with the 

8 "find a friend" feature). This number, which is then read from the card, can then be 

9 linked to a particular user. In certain embodiments, data could also be written to the card, 

10 although only being able to read data from the card is sufficient to take advantage of 

1 1 basic RFID functionality. 

12 In order to speed up claims processing even further and eliminate the need for end 

13 users to carry claim codes around with them, the use of RFID can shift the identification 

14 process to the card carried by the end user, such that when the user wishes to claim a 

15 product (e.g., a beverage) or service, he or she simply hands the venue employee (e.g., 

1 6 bartender) his or her RFID card 1 72 1 . The venue employee waves the card in front of the 

17 short-range reader 1727 at the venue terminal 1726 and this will retrieve any outstanding 

18 claims without data input, thereby increasing the convenience for both parties. For this 

19 feature to work most efficiently, the claim information downloaded by the venue claims 

20 terminal 1726 should desirably include the card ID of the recipient (when there is one), so 

21 that the central system only needs to be queried in the case that there are no matches for 

22 that ID. 
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1 The use of RFID in a system consistent with the invention can also enable * 

2 location-based services, by combining the networked venue claims terminals 1726 with 

3 RFID technology installed in participating venues. The configuration of such services 

4 includes the RFID reader 1723 positioned near the door of the venue, which notes the 

5 entrance and exit of end users who are both carrying their RFID card 1721 and who have 

6 agreed to participate in location-based services. The RFID reader 1723 relays (e.g., via 

7 Bluetooth) this information to the venue claims terminal 1726, where it is further relayed 

8 to the central server (not shown), establishing a complete "map" of which individuals are 

9 in which venues in real or near-real time. To protect user data privacy, the system may 

10 be configured so as not to store such information permanently and/or to overwrite or 

1 1 erase location data relating to an individual when the RFID sensor 1723 reads the card ID 

12 for the second time, indicating the individual has left the establishment. 

13 Further functional protections for end users may be inherent in the setup and 

14 operation of the system, e.g., if a user does not sign up for or carry their RFID card 1721 

15 with them, they will not be visible to the system (although other methods may be 

16 provided for "logging in", e.g., by having a bartender swipe the RFID card 1721 at a 

17 venue claims terminal); in addition, the card may have information providing multiple 

18 ways for a user who has signed up for the service to toggle this feature on and off, e.g., an 

19 SMS number to which a user can send a message from the phone indicated as his or her 

20 phone messaging address, which would trigger an SMS reply showing the changed status 

21 of the service; or alternatively, the WAP end user menu may be configured to allow an 

22 end user to turn on and off location services; or alternatively, the web end user menu may 

23 be configured to allow an end user to turn on and off location services. 
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1 A "map" based on RFID location information may be used in a system consistent 

2 with the invention to provide other services. For example, location-sensitive promotions 

3 may be used, such as a greeting or coupon sent to an end user when they enter a 

4 particular venue. These promotions may be ongoing campaigns triggered by an RFID 

5 proximity event (marketing campaigns are described in further detail hereinabove). For 

6 other registered users who have the ability to see someone's location, the ability to "find 

7 a friend" or see what friends are actually out at the moment may be provided. This 

8 feature may be accessible, e.g., under the friends tab of the end user web interface and the 

9 "find a friend" link in the end user WAP interface. In addition to seeing where a friend 

10 is, the end user may, of course, initiate an expedited purchase for this friend at their 

1 1 current location. 

12 Moreover, an RFID card may be useable as a credit card in a system consistent 

13 with the invention, wherein, instead of ringing up a purchase on their own system, the 

14 venue employee would indicate the total charge on the venue claims processing terminal. 

15 In this configuration, the end user would desirably have to both carry the card into the 

16 venue and have a credit card on file with the system. Just as with a traditional credit card, 

17 those venue claims terminals that run in a "disconnected" (e.g., dial-up) mode would 

18 have to check with the system to make sure a credit card is both stored and valid. 

19 It should further be noted that a permissions system may be used to define strictly 

20 which end users have access to location information for friends or other users, i.e., 

21 whether they are able to view data associated with a given end user, such as Instant 

22 Reciprocity information or RFID location information for the user whose information 

23 will be shared. Since the present invention contemplates that an end user can use a WAP 
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1 mobile phone to communicate with the system, when the end user logs into the web 

2 interface, new permissions requests from other users may be displayed, and a return 

3 email or SMS message, or clicking on a link provided, may be used to grant permission. 

4 Email reminders may be provided when there have been one or more permissions 

5 requests outstanding for a period of time, e.g., two weeks. A secondary matching 

6 procedure may be necessary to address potential synchronization problems. For example, 

7 if a user has a friend in her friends list who has registered with the system using different 

8 messaging addresses from the ones the user has entered, trying to match the messaging 

9 address would result in failure. The secondary matching procedure would use alternative 

10 data, such as a name match and/or the friend's having bought or received a claim from 

1 1 the other user. It is further contemplated that there may be situations where the system 

12 could generate permissions requests automatically, which could be a user-selectable 

13 setting, e.g., a user might want to request permission to see anyone for whom the user 

14 buys a drink. In certain embodiments, a user may be able to request permission from 

1 5 another user only a certain number of times or at a certain interval. A permissions 

16 request can either be pending, granted or denied. Once permissions have been granted, it 

17 the "grantor" would have the ability to revoke sharing permission as well. 

18 Further RFID card functionality may include features for activating and/or 

19 requesting an RFID card to use with the system. It should also be recognized that other 

20 user identification devices may be used in a system consistent with the invention, e.g., an 

21 account or identification number, a charge/credit /debit card, a loyalty/affinity card, a 

22 customer identification card, a wand or tag, or even a driver's license. 



57 



1 While the location-based services as described herein are described as 

2 implemented using RFID, it should be recognized that alternative location-based 

3 methodologies may be used in a system consistent with the invention, e.g., global- 

4 positioning system (GPS) or other wireless location services, e.g., Bluetooth, 802. 1 1 or 

5 mobile telephony tower-based triangulation. Tokens (i.e., devices) for RFID or other 

6 wireless technologies that may be used with a system consistent with the invention 

7 include chipless tags, coil-on-chip devices, contactless smart cards, key fobs, and even 

8 mobile telephones. Thus, it is contemplated that many types of tokens and token 

9 detectors employing a wide range of technologies may be employed in a system 

1 0 consistent with the present invention. 

11 System Administration 

12 It is contemplated that a system administrator controls the structure and operating 

13 parameters of the system as well as daily system operation and management. For day-to- 

14 day system operations, the system administrator may access most functionality directly 

15 through a web interface. The interface may be organized into five main categories (as 

16 illustrated in the exemplary screen views 1800, 1900 of Figures 18 and 19): account 

1 7 (which includes editing/deleting current administrators, and name and password, and 

18 adding a new administrator), system setup, user management, marketing/mining, and 

1 9 system management. 

20 System setup may include features for a system administrator to establish the 

21 system's initial structure and operating parameters, and once the system is operating, 

22 most of these settings will not be able to be changed. Exemplary features (as illustrated 

23 in the exemplary screen view 2000 of Figure 20) include: interface, design of user 
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1 registrations, , design of distributed directory listing, and system parameters. The system 

2 interface may have an editable style sheet, color palette and logo area, and options may 

3 be provided for editing the style sheet, color palette, and logo (including uploading a new 

4 logo and choice of placement). Design of user registrations may include functionality for 

5 the administrator to construct registrations for each user type by selecting from a list of 

6 supported fields. In the case of the end user, there may be two registrations, one to use the 

7 system and a separate registration for the rewards program. Custom fields may also be 

8 supported. In addition to selecting and ordering the fields, the administrator may provide 

9 the following exemplary information for each field: whether the field is required on 

10 registration; for numeric fields, minimum and maximum values (if any), for text fields, 

1 1 minimum and maximum number of characters, and for encoded fields, and number of 

12 responses and labels. For the design of distributed directory listing, the administrator 

13 may construct a directory listing by selecting fields from a list. Venue items in the listing 

14 may automatically be included in the venue registration. The system may also support 

15 custom listing fields. The following exemplary information may be provided for each 

16 item selected: if not implicit, the user type who can modify this field; certain fields 

17 associated with encoded responses that may require the administrator to set the number of 

1 8 encoded responses and attach labels to the responses; for custom fields, the administrator 

19 may have to supply the field name, the data type and associated encodings if any; 

20 whether the field will be preset with a response, and if preset, whether it is locked; 

21 whether the item is required or not; and an important part of this process will be 

22 structuring the fields describing the products that can be purchased through the system. 

23 The administrator may encode the product subcategories. When a slot for a product is 
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1 added to the listing, the administrator can attach it to a particular subcategory or let a 

2 venue put a product of any type into the field. System parameters (which may be 

3 subdivided into general, campaign, purchase, and account parameters) may also be set by 

4 the administrator. For example, general parameters might include countries banned from 

5 participating in the system. Campaign parameters might include the total number of open 

6 campaigns allowed, the days in advance all campaigns must be scheduled (so that the 

7 system administrator can receive each campaign mailing in advance of the community), 

8 and for each user group (venue, member, third-party marketer), the number of campaigns 

9 allowed per individual, the base cost per person per campaign for MMS, SMS, and e- 

1 0 mail, and the additional cost per variable for MMS, SMS, and e-mail. Purchase 

1 1 parameters might include the surcharge per transaction, the length of time in days before 

12 an open claim is closed (90 days), the number of days before a claim is closed to send 

13 reminder notice (i.e., 0 days means no notice will be sent), and the number of bad 

14 transactions (or bad cards) before an end user is banned from the system. Purchase 

15 parameters may also include, for those users who are new (e.g., in the first month of 

16 service), a cap on the user's first transaction, a cap on any single transaction thereafter, 

17 and a cap for total purchases in a 48-hour period; and for users who do not store cards on 

1 8 file but have made a purchase that cleared more than a month ago, and a cap for any 

19 single transaction, a cap for total purchases in a 48-hour period; and for those users who 

20 have stored cards on file and made a purchase with the currently stored card more than a 

21 month ago, a cap for any single transaction and a cap for total purchases in a 48-hour 

22 period. Account parameters may include, for each user group (venue, member, third- 

23 party marketer), the registration fee (if any), monthly fee (if any), the frequency of 
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1 account reconciliation (probably every 2 weeks), the minimum value of an account 

2 balance to lead to a transaction, the maximum coupon debit allowed (coupons may be 

3 good for up to, e.g., a maximum of 90 days), and the maximum outstanding account 

4 balance (wherein, when exceeded, either immediate reconciliation or a freeze on account 

5 might occur). 

6 User management functionality may include the following exemplary features for 

7 interacting with system users (as illustrated in the exemplary screen view 2100 of Figure 

8 21): manage approvals (an interface allowing the administrator to review and grant/deny 

9 items for approval that can be viewed by category/type, e.g., venue/third-party marketer 

10 registration, push campaigns, rewards, closing of accounts), manage accounts (an 

1 1 interface allowing the administrator to manually activate/freeze/close a user's account, 

12 wherein a deactivated account will fail at login; in addition, there may be a list of banned 

13 messaging addresses, wherein if the address corresponds with a user account, the account 

14 is automatically frozen), and communications (an interface allowing the administrator to 

15 select user group or subset category to deliver a message to, wherein messages are be 

1 6 processed to the default messaging contact address associated with the user record). 

17 Marketing and mining functionality may include the following exemplary tools 

18 for marketing to users and mining system data (as illustrated in the exemplary screen 

19 views 1200-1600 of Figures 12 through 16): promotions (including an itemized list of 

20 promotions, wherein the user can view active or all, and can modify a service that has not 

21 been delivered, delete/cancel a service that has not been delivered, user the service as a 

22 template for new, and view summary statistics for services that have been delivered), 

23 create a new promotion as either a push campaign (specifying a coupon, message and/or 
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1 survey) or a reward system, and data mining (including capabilities to view/search data, 

2 export data, and perform analysis and mining (described in further detail hereinbelow). 

3 System management functionality may include the following exemplary tools for 

4 managing/monitoring the system (as illustrated in the exemplary screen view 2200 of 

5 Figure 22): system monitoring/maintenance (allows the administrator to check uptime 

6 and performance/responsiveness of server software, communications with venue client 

7 software, and messaging and system activity; maintenance functionality may allow 

8 system components to be taken offline without affecting other components), scaling/load 

9 balancing (a setting that allow for load balancing and scaling of the system across 

10 multiple machines), and performance reports/testing (system performance or 

1 1 responsiveness testing modules). 

12 In the case of a self-host business model, the system administrator may be 

13 responsible for selecting and integrating third-party solutions to the system. Of course, 

14 the system administrator is likely, in most cases, to have access to the core system code 

15 and hardware, thereby enabling an administrator that wants to add functionality or 

16 equipment to the system directly to do so by modifying the codebase or system 

17 equipment. 

18 Payment Processing. Billing and Reconciliation 

19 Several kinds of financial transactions may take place in a system consistent with 

20 the present invention, and it is contemplated that such a system may handle payment 

21 processing for purchases or various system fees, or alternatively, that such functionality is 

22 handled externally, or by a third-party provider. System fees may include, e.g., one-time 

23 registration fees and/or ongoing monthly fees. User may also incur fees as they buy 
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1 services and when coupons they have issued are used by end users during transactions. 

2 Likewise, account balances may be kept for venues, which may be credited for goods 

3 they provide and may be paid by the system. It is contemplated that such venue accounts 

4 would be reconciled biweekly, and funds transferred if the owed balance is higher than a 

5 level set by the administrator. At the time of reconciliation, the system may also generate 

6 an e-mail to the venue indicating which products have been given out to assist the venue 

7 with reordering supplies. 

8 In general, during reconciliation periods, it is desirable that the system would bill 

9 a credit card associated with an account for debits and to credit that card (or perform an 

10 electronic fund transfer) to accounts with credits in order to minimize human interaction. 

1 1 In certain embodiments, it is possible in the case of members and third parties that 

12 invoices would have to be generated and payments collected manually, and in this 

13 scenario, the administrator is provided with a mechanism for manually adjusting balances 

14 to reflect payments received. 

15 It is contemplated that transactions that take place in a system consistent with the 

16 present invention may or may not involve direct payment processing. The system may 

17 maintain a series of account balances associated with individual users, venues and third- 

1 8 party marketers, whereby, as transactions flow through the system, these balances are 

19 adjusted (e.g., as illustrated in table below). This methodology may be employed in order 

20 to guarantee better service and reduce fraud risk. Operating under the parameters set by 

21 the system administrator, these balances may be periodically examined and if they meet 

22 certain criteria are cleared via a reconciliation process that initiates billing or payment 



63 



1 processing. The following table provides a set of exemplary transactions that might take 

2 place in the system: 



User Type 


Transaction 


System Activity 


Notes 


Anonym. 
End User 


Anonymous 
transaction 


Processes payment charge 
directly. 


Transaction will not be 
released until charge 
clears. 


End User 


Opens 

account/Adds 
to user 
balance 


Processes payment charge. 
Credits user balance same 
amount 




End User 


Makes 

product 

purchase 


Debits the end user's credit 
card or payment type 
amount of purchase less 
any coupon or promotion 
credits. The coupon or 
promotion credits are 
debited from the account of 
the issuer. 


Can be immediate 
process or batched 


End User 


Uses RFID 
card as credit 
card in venue 


Debits user balance amount 
charged and credits venue 
amount charged less 
transaction fees 




End User 


Pays for 


Instead of user balance 
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product with a 
buy n get nth 
free "coin" 


being debited price of 
product, administrator is in 
the form of a credit to the 
venue. 




End 

User/Venue 


Redeems or 
fFulfills a 
product claim 


Credits venue balance 
amount of claim minus 
transaction fees 




Venue/ 
Member/ 
Third-Party 
Marketer 


Purchases 
marketing or 
advertising 
services 


Debits buyer's account cost 
of those services. 


May prompt immediate 
payment processing. 
Some services, e.g., 
coupons and pay-per- 
response may be 
debited as they are used 


Venue/ 
Member/ 
Third-Party 
Marketer 


Opens 
account 


Debits account balance 
registration fees (if any) 




Venue/ 
Member/ 
Third-Party 
Marketer 


Monthly 
period ends 


Debits account balance 
monthly fees (if any) 




Venue 


Cancels or 
refunds claim 


Credits user balance 
amount of transaction. 
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Debits vendor that amount 
minus transaction fees. 




Venue 


Reopens 
claim 


Debits venue balance 
amount of claim minus 
transaction fees. 




Venue/ 
Member/ 
Third-Party 
Marketer 


Closes 
account 


Processes payment to/from 
venue in amount of balance 
to clear balance to zero 


Requires administrative 
approval 


System 
administrator 


Uses 

marketing or 

advertising 

services 


If applicable, credits 
participating system 
balances. 


This category may 
include administrator 
supported 
discounts/rewards, 
tokens 


System 
administrator 


Reconciles 

account 

balances 


Processes or provides 
payment in amount of 
balances to 

venue/marketing accounts 
to zero them out. 


Minimum clearing 
parameters may be set 
by administrator. 


System 
administrator 


Closes an 
account 


Processes or provides 
payment in amount of 
balance to zero out. 


Override by 
administrator. 



1 
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1 In order to prevent fraud on the part of individuals making anonymous one-off 

2 transactions, the system administrator is able to cap the total of each anonymous 

3 purchase. In addition, because the recipient is captured in the claim record, the 

4 administrator is also able to cap how many anonymous transactions a single recipient can 

5 receive in a twenty-four hour period. Finally, the system may keep track of recipient 

6 messaging addresses in cases where the payment information later proves to be 

7 fraudulent or contested. The administrator is able to set the number of repeat incidents 

8 that cause these addresses to be banned from the system. The administrator may also be 

9 able to set caps for new users, e.g., during a probationary period, for users who do not 

10 have stored payment in the system, and may be able to block the use of credit or debit 

1 1 cards originating from certain fraud-prone countries. 

12 With the exception of anonymous end users and registered end users who choose 

13 to re-enter their payment information each time they wish to transact, the system may be 

14 adapted to store payment information for each system user. This information will 

15 generally be collected at the time of registration, and may be changed at any time by the 

16 system user (login is required). This information will be used in processing payments or 

1 7 generating bills associated with the account. 

1 8 For individual payment processing and account reconciliation, certain transactions 

19 in the system result in immediate individual payment processing or account 

20 reconciliation, e.g.: when a registered end user purchases credits; when an anonymous 

2 1 user makes a one-off transaction; and when a venue or third-party marketer account 

22 balance crosses a threshold set by the administrator. For batch processing and account 

23 reconciliation, excluding the special cases that prompt individual processing, account 
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1 reconciliation (and accompanying payment processing/billing) may normally be done in 

2 batches at a frequency and under the parameters set by the administrator. A reconciliation 

3 will generate a batch of payments requiring electronic payment processing, a batch of 

4 payments for physical billing and a batch of payments for check generation. In addition, 

5 it will produce itemized log files for each of the accounts that have been reconciled. The 

6 system may connect to a third-party solution provider via an API to provide billing (both 

7 electronic and physical distribution) as well as a check printing and distribution service. 

8 The solution can support, e.g., debit/credit card processing, direct deposit/withdrawal 

9 and, possibly online payment mechanisms, e.g., PayPal™. It is contemplated that all 

10 parties are able to access their account balance on a real time basis (login is required 

1 1 through the users' respective system interface). 

12 User Accounts (Features and Interfaces) 

13 It is contemplated that, in a system consistent with the present invention, end 

14 users are able to access the system through a variety of clients, including, but not limited 

15 to: a web browser on a desktop or laptop computer, a WAP browser on a smart phone, a 

16 phone based automated voice system and a wireless fat client application (such as a 

1 7 J2ME) application. 

18 A menu of exemplary features is illustrated in the exemplary screen views 2300- 

19 3000 of Figures 23 through 30. It should be recognized by those skilled in the art that not 

20 all features will be available on all clients, and some features are conditional on the basis 

21 of such criteria as whether the user is registered and logged in (or using the system 

22 anonymously), whether the user currently has open claims in the system, and whether the 
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1 user has entered information required to activate some of the more advanced functionality 

2 (as discussed in further detail hereinbelow). 

3 Exemplary main menu options, in one embodiment of the invention, are: home 

4 (for login and registration, as illustrated in the exemplary screen view 2300 of Figure 23), 

5 account, browse venue directory, make a remote purchase, unredeemed claims, friends, 

6 and rewards program. 

7 In embodiments of the present invention requiring user registration, the home 

8 menu may only support end users who have previously registered in the system. In this 

9 scenario, unregistered users and recipients of drinks may be guided to a link where they 

10 can "take a tour of the system" or register (both touring and registration may first require 

1 1 that a user certifies he or she is of legal drinking age in an alcoholic beverage 

12 implementation of the present invention, using an interface such as that illustrated in the 

13 exemplary screen view 2310 of Figure 23a). Also, new promotions, announcements, 

14 advertisements, and other information may be displayed at this menu. Cookies may be 

15 used to permit registered users to skip the home page entirely and bookmark subpages. 

16 Appropriate functionality may be provided for users who have forgotten their userlD 

17 and/or password, wherein the system looks up the user by primary messaging address and 

1 8 sends a new password to that account 

19 An exemplary account menu may provide the following selectable options: profile 

20 and payment. The profile submenu, as illustrated in the exemplary screen view 2400 of 

21 Figure 24, provides the following selectable options: name, user ID, password, WAP 

22 client PIN, and phone/email messaging addresses. Multiple messaging addresses may be 

23 specified, and one should desirably be a valid phone or email messaging address, the 
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1 primary address for receiving claims, and a preferred address may be marked as such. 

2 The payment submenu shows current balances and provides the following selectable 

3 options: add/delete payment information, as illustrated in the exemplary screen view 

4 2500 of Figure 25 (e.g., credit card; up to 2 may be specified, with primary indicated, 

5 wherein each payment type has a pin # used as a confirmation and to access), purchase 

6 more credits, set up automatic debit (on/off, recharge to b when balance goes below c, or 

7 automatically charge d each month to primary payment type), and transaction history, as 

8 illustrated in the exemplary screen view 2600 of Figure 26 (e.g., last 50 purchases, unsent 

9 claims, recurring claims). The transaction history selection may further provide options 

10 to repeat this purchase or make this purchase recurring, or modify (can only be done if 

1 1 claim is unsent or recurring), edit, or cancel a purchase. An alternative transaction 

12 history screen view 2 

13 An exemplary browse venue directory menu may provide the following selectable 

14 options: initiate purchase, rate this venue (only available to registered users; on a scale of 

15 1-5), and provide feedback about this venue. Venue directory functionality may include 

16 using a search field to enter the name of a venue or city, selecting a city from a city list, 

17 or clicking on a location on a map graphic (e.g., as shown in the exemplary screen view 

18 2610 of Figure 26a). Once a city is selected, a map of the city may be displayed, as 

19 illustrated in the exemplary screen view 2620 of Figure 26b, from which a user may 

20 select a venue or a region or neighborhood (for larger metropolitan areas, wherein a user 

21 would next be shown a map of the region or neighborhood from which a venue may be 

22 selected, e.g., as illustrated in the exemplary screen view 2630 of Figure 26c). 

23 Alternatively, a user may select a venue list by category (e.g., pub, bar, restaurant, club, 
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1 late-night, top rated: top 5% for city, gay/lesbian). A venue list is then shown, including 

2 brief descriptions of the venues, as well as detailed venue information. This may be 

3 shown, for example, using symbols next to the name of the venue indicating certain 

4 information, e.g.: top rated (top 5% of ratings for the city), restaurant/dining, pub, bar or 

5 club, open late, gay/lesbian/bisexual, as well as drink (and/or food) menu/pricing for the 

6 selected venue. A user-selectable button or other feature is desirably located on the 

7 venue information screen, as well, so that a user may initiate a basic purchase. 

8 Selecting the "make a remote purchase" option is another way of initiating the 

9 purchasing process, as described above and illustrated in Figures 2a-3b. 

10 An exemplary unredeemed claims menu may provide the following selectable 

1 1 options: resend claim and show the venue information page. If the user is an unregistered 

12 user, the system will prompt them for the messaging address where they received the 

13 claim. 

14 An exemplary friends menu may provide the following selectable options: instant 

15 reciprocity settings, as illustrated in the exemplary screen view 2700 of Figure 27 (which 

16 may include, e.g., select/replace my favorite venue and/or product), "hint-hint" submenu 

17 (wherein the user broadcasts a message to someone else to purchase something for 

18 him/her), and a friends list submenu. The "hint-hint" submenu provides options to add, 

19 delete and modify an event, as illustrated in the exemplary screen view 2800 of Figure 

20 28, which may comprise the following five exemplary fields: type (birthday, anniversary, 

21 custom text), reminder message, selected venue and product (automatically fills in instant 

22 reciprocity values), recipients, and send date (with an option to make it recurring). 

23 Alternatively, a hint-hint screen may appear as shown in the exemplary screen view 2810 
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1 of Figure 28a. As shown in Figure 29, an exemplary screen view 2900 comprises a list of 

2 scheduled events. The friends list submenu may comprise the following options: settings 

3 and view friends list. Settings for the friends list may include making the user's profile 

4 public/private (when a user adds friends or imports, the system looks for messaging 

5 address matches with other system users, and if it finds a match and the profile is public, 

6 the friend record will be replaced by a pointer to the friend's, i.e., the other user's, 

7 information, thereby allowing for dynamic reflection of changes) and whether to 

8 automatically add anyone who purchases a product for the user to his friends list. The 

9 view friends list functions (as illustrated in the exemplary screen view 3000 of Figure 30) 

10 may include add a friend (with fields for name, one or two messaging addresses, with the 

1 1 primary address indicated, and venue/drink they like), import addresses from external 

12 address book (e.g., Microsoft Entourage or Outlook, wherein fields needed by the system 

13 are extracted, i.e., name, messaging addresses, cell phone, secondary email), delete a 

14 friend, and making, editing, and deleting groups of friends. In addition to manual entry 

15 of information into the friends list, a drag-and-drop interface may be provided for adding 

16 single or multiple entries to the friends list from other software packages, e.g., Microsoft 

17 Entourage or Outlook. At a minimum, it is contemplated that the following exemplary 

18 fields would be part of each entry in the friends list: first name, last name, email 

19 messaging address and/or phone messaging address. Additional functionality may be 

20 provided at the friends list menu, such as a graphic of a map with dots plotted thereon in 

21 each city, country, region, or neighborhood where the user has a friend or group member, 

22 along with the display of a list of all friends and groups, as shown in the exemplary 

23 screen view 2710 of Figure 27a. Other functionality may include a feature for locating a 
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1 friend who is at a venue (by using RFID find-a-friend to bring up a list of all friends 

2 found and then viewing a plot of them on a global map). An exemplary displayed list of 

3 friends and/or groups is shown in the exemplary screen view 2720 of Figure 27b. From 

4 the friends list, the user may select a friend and then perform functions such as seeing 

5 their location and instant reciprocity information (if the user has permission to do so), 

6 initiating a purchase for the friend (including pre-population of fields to the extent 

7 possible), editing the listing for that friend, requesting permission to see their 

8 location/instant reciprocity information, and deleting the friend from the list. From the 

9 groups list, the user may initiate a group purchase (including pre-population of fields to 

10 the extent possible), edit the group (i.e., add/delete members), or delete the group. Other 

1 1 friends functionality may include changing sharing/permissions settings (e.g., 

12 automatically granting permission to anyone who has made a purchase for the user, or 

13 making the user visible, i.e., granting permission to all users in the system), approving or 

14 rejecting pending permission approvals, turning all approvals on/off, and turning an 

15 individual approval on/off. 

16 As mentioned above, not all of the above functionality is made available for all 

17 clients. The chart below details the functionality that might be available on various 

18 exemplary clients and under various exemplary circumstances: 
19 
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1 A system consistent with the present invention may also provide end users with 

2 the ability to access the system via a telephone call. Two methods of implementation are 

3 contemplated. First, such access could be handled through a call center. In this case, call 

4 center agents equipped with computers will access as a proxy for taking and entering 

5 orders and responding to information requests. A second, less expensive method of 

6 implementation calls for using a touchtone and/or voice-driven automated call system. 

7 Instead of providing the menu functionality described above, a script or map of the 

8 automated voice menu system might provide the following limited exemplary 

9 functionality: 



10 Main Menu: 

11 • 1 to search for a venue (or say "search") 

12 • 2 to buy remotely (or say "buy") 

13 • 3 if you are a purchase recipient and need assistance (or say "claim") 

14 • 4 if you purchased remotely and need assistance (or say "purchase") 

15 (1) Search: 

1 6 • Enter Postal Code for the area in which to search or # to spell out city 

17 name if postal code is not known (or speak zip code or city name) 

18 ■ 1 to pick one at random (or say "random") 

19 ■ 2 to pick highest rated in area (or say "high rated") 

20 ■ 3 to look up by name (spelled out using keys) (or say "name") 

21 ■ 4 to look up by category (spelled out using keys) (or say 

22 "category") 

23 • Matches are returned and presented as a menu (If only one, skip this step). 
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1 Choose the number of selection or # to go back (or say "name" or "back") 

2 • The system reads out the venue information 

3 ■ 1 to buy remotely (or say "buy") 

4 ■ 2 to repeat all info (or say "repeat") 

5 ■ 3 to repeat phone number/initiate call (or say "call") 

6 ■ 4 to repeat address (or say "address") 

7 ■ 5 to start a new search (or say "new") 

8 (2) Buy: 

9 • For whom? (this will be recorded via speech to text) 

10 • Enter phone number of recipient. Confirm, (manual entry or voice) 

1 1 • Where? (if not already implied by path) 

12. • See search process above. This process returns after a venue has been 

13 selected (before the supplies venue information step) 

14 • What? (reads products/prices for selection) (manual selection or voice) 

1 5 • How many? (key in number or voice) 

16 • Confirms total cost (key 1 to confirm or say "confirm") 

1 7 • Select payment type (manual selection or voice) 

1 8 • Key in payment number (manual selection or voice) 

19 • Record a message for the recipient (this will be recorded via speech to 

20 text) 

2 1 • Confirmation message and order number is read by the system 

22 (3) If you received a claim: 

23 • 1 for general explanations/instructions (or say "help") 
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1 2 to enter claim number for venue information (or say "claim number") 

2 • 3 if you lost your claim number (or say "message address" or "phone 

3 number") 

4 (4) If you purchased: 

5 • Enter claim number (or say claim number) 

6 ■ 1 to resend claim to recipient (or say "resend") 

7 ■ 2 to modify open claim information (or say "modify") 

8 ■ 3 to change recipient phone number (or say "change") 

9 ■ 4 to change other (or say "other") 
10 

11 It is contemplated that end users may have a number of ways to become registered 



12 members of the system. They can choose to register when they initiate a purchase 

13 process, as part of their response to a claims notification and via an invitation initiated by 

14 a registered user. Registering gives the end user a number of advantages: it eliminates 

1 5 some of the data entry required during purchasing/responding to transactions, it allows 

16 the end user to make real-time purchases instead of having to wait for the charge to clear, 

17 and it allows the user to personalize the system in various ways, e.g., build friends list, 

18 setting alerts for events (birthdays/anniversaries), opting into and receiving information 

19 about special offers from third-party marketers or venues and so on. 

20 As described hereinabove, the administrator defines the information end users 

2 1 need to provide during the registration process and parameters affecting end user system 

22 use. Exemplary end user information that might be required at registration (as illustrated 

23 in the exemplary screen view 3 100 of Figure 31) includes, e.g.: user ID, user password, 
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1 payment type and information (and, optionally, the capability to keep such information 

2 on file along with additional payment settings), number of credits they wish to purchase 

3 initially (there may be a system minimum), contact information (at least a valid email 

4 address, and possibly may supply up to 3 messaging addresses, including a telephone 

5 number for SMS text messaging and/or MMS communications). Additionally, country 

6 and language information may be gathered manually or automatically. The user might 

7 also be able to perform the opt-in marketing registration and enter instant reciprocity 

8 information and referral information. Further, at the time of registration, functionality 

9 may be provided to permit importation of phone numbers and/or email addresses into a 

10 friends list. Demographic and marketing information may further be collected, either at 

1 1 the time of registration or at a later time. Such additional exemplary information may 

12 include personal information and other settings, as illustrated in the exemplary screen 

13 views 3200-3420 of Figures 32 through 34b. Personal information captured during the 

14 opt-in marketing registration may include language, country, state, postal code, gender, 

15 age, occupation, income, whether user is planning to switch jobs in the next 6 months, 

16 favorite magazines, frequency of drinking daily/weekly, etc.), whether the user owns or 

17 rents a home; favorite designer brands (from a list), frequency of going out, favorite 

18 travel destination (by country), favorite sports (by type), favorite music type (by genre), 

19 favorite TV shows (by category), favorite brand of watch (by type), and favorite car (by 

20 manufacturer/type). Initial reward opt-in settings may include: periodic surveys in which 

2 1 the user can win prizes (on/off, to which address, number/week, hours available), 

22 coupons (on/off, to which address, number/week, hours available), and other offers 
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1 (on/off, to which address, number/week, hours available). Users will be able to opt-in/out 

2 and change this information either during registration or at any point thereafter. 

3 In order to activate instant reciprocity functionality, the end user will have to 

4 designate certain information, e.g., a favorite venue and product from that venue 

5 (described in further detail hereinabove). 

6 Venues 

7 As described hereinabove, the administrator typically approves venues that wish 

8 to join the system and the information they need to provide during the registration 

9 process. In addition to becoming registered members of the system, it is desirable that 

10 participating venues be required to install and run the client software necessary for 

1 1 processing claims on-site. The software should therefore run on a device that has a 

12 continuous connection with the system's central server via the TCP/IP protocol. Venues 

13 may access the system via one of two exemplary interfaces: a web interface for 

14 registering and managing the account, including accessing most services, and a claims 

15 software interface for receiving and processing claims transactions. 

16 The venue web interface may provide the following exemplary features, grouped 

1 7 into the categories of account, venue directory listing, claims, marketing, and contact 

18 administrator. Account information may include profile, payment, and close account 

19 options. Profile options may include contact information (an area to modify contact 

20 name and details) and employee user IDs and passwords (an area to add/delete users and 

21 edit passwords, and whether the employee is a manager). Payment options may include 

22 current system balance (includes next anticipated billing/payment date), pay it now (a 

23 feature for manually initiating payment in case of a debit balance), payment information 
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1 (an area to modify payment type and details), tax ID number, and transaction history 

2 (which may include features such as show transaction summaries and export transaction 

3 data). The close account feature clears the balance and makes the account inactive, and 

4 may require approval from an administrator). A venue directory listing option that might 

5 be provided is the ability to modify the listing. Claims options may include open claims 

6 (itemized list of all open claims), cancel/refund claim (per system administration 

7 guidelines), history (e.g., last 120 days of redeemed claims), reopen claim (if accidentally 

8 redeemed), export data, and view and/or export summary statistics. Marketing options 

9 may include campaigns (itemized list of activities including associated schedule, details, 

10 and pricing information), modify (allows a service that has not been delivered to be 

1 1 modified or cancelled), delete/cancel, use as a template for new campaign, and for 

12 campaigns that are complete, view summary statistics. A contact administrator function 

1 3 may further be provided. 

14 The system may be configured so that users with an employee ID will not be able 

15 to access the venue interface at all unless the venue operator indicates under preferences 

16 that they are a manager. If so, they may only be able to access the venue directory listing 

1 7 tab of the interface. 

18 It is contemplated that the venue claims software is run in real time to process 

19 claims at the venue site. The software should therefore be running on a device capable of 

20 receiving incoming data about claims via the TCP/IP or messaging protocol at real or 

2 1 near real time. The venue claims software should require a userlD (or employee ID) and 

22 password to be activated. The venue client software may include the following exemplary 

23 menus and features, grouped into preferences and claims functions. Preferences may 
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1 include connection type/speed, batching (allows for completed claims to be batched and 

2 uploaded to the system asynchronously), and display claims default (sorted by time, 

3 present day's only and other options for the claim display; also whether/when closed 

4 claims should no longer be displayed). When the user selects an option to change claims 

5 functions, the application may load to this point and display open claims and the 

6 following exemplary claim functions as set in the display claims preference: search 

7 (string), sort (by time, by date, alphabetically, by number), redeem (indicates the product 

8 has been redeemed by the recipient), cancel/refund (according to system administrator 

9 presets), and reopen (if a claim has been accidentally closed). 

10 Users with an employee ID should not be able to access the preferences tab in the 

1 1 client software unless they have been designated under preferences that they are a 

12 manager. In addition, only employees who have been designated as managers should be 

13 able to cancel/refund and reopen claims. 

14 Exemplary venue information that may be required at registration includes user 

15 ID, owner password, employee IDs and passwords (gives employees access to the events 

16 calendar in the web interface and to the claims software), contact name and details, 

17 business name, billing address and payment details, including tax ID number, and venue 

1 8 listing information, including specific products and prices (listing information is available 

19 to other system users, as described hereinabove). 

20 Venue Claims Terminal 

21 In certain embodiments, the foregoing described venue interface functionality 

22 may be implemented using one or more specially-configured venue claims terminals 

23 located in a venue, through which all of the foregoing described venue functionality (in 
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1 particular, purchase/claim notifications to the venue) may be directly implemented. It 

2 should be recognized that the venue claims terminal may be coupled to or integrated into 

3 an existing point-of-sale system using appropriate hardware and/or software. 

4 In one embodiment, using the venue claims terminal begins with the user being 

5 presented an initial login/home screen showing two user-selectable buttons: begin claim 

6 processing and preferences. Clicking on begin claim processing should cause a 

7 disconnected modem terminal to begin its dialup cycling, while the venue administrator 

8 or employee logs in with his or her userlD. The preferences button may be used by the 

9 venue administrator to change connection type and/or speed information (e.g., 

10 dialup/Ethernet), dialup numbers and backup numbers, and other processing options, e.g., 

1 1 whether employees need to type their user ID each time they process a transaction, and 

12 whether the terminal will accept RFID cards as credit cards. 

13 In the claims processing mode, several buttons are presented to the user for 

14 selection. If employees need to supply their user ID per transaction, they should be 

15 prompted for this information immediately after selecting any of active buttons: claim, 

16 coupon, upload/download, credit, help, correct error, and logout. The claim button 

17 allows the employee to type in the claim code. If the claim is not in the terminal memory, 

18 this will initiate an automatic communication with the central system to find the record. 

19 After the claim has been brought up, the employee hits a redeem button to close the 

20 transaction and return to the claims processing home screen. The coupon button allows 

21 an employee to enter in a redeem at venue coupon number. After the coupon has been 

22 called up, the employee hits a redeem button to close the transaction and return to the 

23 claims processing home screen. When the upload/download button is selected and the 
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1 claims terminal is in dialup mode, the terminal initiates an upload/download of new 

2 information with the core system (whereas this information may be updated in real time if 

3 the terminal is always connected to the system (e.g., via Ethernet). The "credit" button 

4 may be used to initiate a purchase where the RFID card is used as a credit card. The 

5 amount of the purchase will be keyed in and then the terminal will ask for the card to be 

6 held up to the reader. After checking with the central system, the screen will indicate 

7 whether or not the card has been accepted. The "help" button may provide phone 

8 numbers for support. The "correct error" button may allow the venue manager to review 

9 recently redeemed or closed transactions, either to visually review and correct an error or 

10 to reopen a transaction. The log out button exits processing mode and modem dialing. 

1 1 As discussed hereinabove, if a short range RFID reader is provided with the venue 

12 claims terminal, a patron may, e.g., hand his or her RFID card (or other token) to a 

13 bartender, who waves the RFID card in front of the short range reader, and all claims 

14 associated with the user may be shown (or, if none are found, an automatic 

15 communication with the central system may be initiated). A venue might also provide its 

16 employees with RFID cards or other tokens that may be used to identify the employee, in 

17 addition to, or instead of the employee being prompted for login/password information. 

18 Third-Party Marketers 

19 Third-party marketers should be registered users in order to participate in 

20 marketing, advertising and data mining activities. As previously described, the 

21 administrator typically approves third-party marketers who wish to join the system, and 

22 sets the information they need to provide during the registration process. It is 

23 contemplated that third-party marketers should be able to access the system and their data 
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1 only through a web interface, and after supplying a valid user ID and password. The 

2 third-party marketer interface may include the following exemplary menus and features: 

3 Account, marketing, and contact administrator. Account information functions may 

4 include profile information (e.g., contact information, with an area to modify the contact 

5 name and details), payment, and close account. Payment features may include current 

6 system balance (includes next anticipated billing/payment date), pay it now (a feature for 

7 manually initiating payment in case of a debit balance), payment information (an area to 

8 modify payment type and details), and transaction history (including show detailed 

9 summary and export data). The close account feature, which may require administrator 

10 approval, clears the balance and makes the account inactive. Marketing options may 

1 1 include campaigns (itemized list of activities including associated schedule, details, and 

12 pricing information), modify (allows a service that has not been delivered to be modified 

13 or cancelled), delete/cancel, use as a template for new campaigns, and for campaigns that 

14 are complete, view summary statistics. A contact administrator function may further be 

15 provided. Exemplary third-party marketer information that may be required at 

16 registration (as illustrated in the exemplary screen view 3500 of Figure 35), includes: 

17 unique third-party ID (assigned by system and used as system identifier), user ID, 

18 password, contact name and details, business name, business address and details, 

19 including tax ID number, and payment type and details (typically an electronic fund 

20 transfer number). 

21 Alternative Embodiments 

22 It should be understood that, although most purchases made using a system 

23 consistent with the invention will involve the specification of a certain product, recipient, 
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1 and physical location, it is contemplated that purchases may be made without specifying 

2 a product, recipient, or physical location. For example, instead of specifying a product, a 

3 purchaser might be able to specify a credit of a particular monetary amount that may be 

4 used at one or more venues, as an electronic gift certificate or a bar "tab". Alternatively, 

5 it is conceivable that a purchaser might use the system to buy a product or service for 

6 himself or herself, in which case there is no third-party recipient. In another scenario, 

7 instead of specifying a single physical location, the purchaser might be able to specify a 

8 plurality of possible physical locations, or a chain of establishments (e.g., of restaurants, 

9 pubs, or consumer electronics stores), whereby the recipient could go to any of the 

10 establishments in the chain to claim a product or service, rather than only a single 

1 1 physical location. 

12 Further functionality may be provided to support emerging technologies, and in 

13 particular, wireless technologies. For example, it is anticipated that a system consistent 

14 with the invention might extend the functionality of claims to allow for claim notification 

1 5 to the recipient via the Multimedia Messaging channel (MMS or picture messaging). 

16 Specific functionality may include the ability for the purchaser to attach a live 

17 picture/video and short audio clip and/or short animated video or themed picture to the 

1 8 claim notification. It is also anticipated that a system consistent with the invention will 

19 support a "fat-client" (device-native) implementation of the system interface for end- 

20 users that provides them with functionality as full as that currently available through the 

21 web interface. The system may also support location-based (e.g., GPS or RFID) 

22 technologies that allow an end-user to pinpoint the location of a friend in order to ensure 

23 more precision in choosing a location. Also, a venue search feature may be provided 
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1 wherein users can ask which venues are close to their current location based on a 

2 location-based reading taken. It is further contemplated that network-enabled terminals 

3 or other communications devices, e.g., touch-screen kiosks, may be operated in some 

4 venues or other physical locations to facilitate the use of a system consistent with the 

5 invention for certain users, e.g., individuals without their own personal PDA, wireless 

6 phone, or similar device. 

7 It should be noted that, although the exemplary system described herein is 

8 adapted for the remote purchase of beverages, the purchase of all types of products other 

9 than beverages is contemplated. Further, the use of the term "products" herein is not 

10 meant to be interpreted as limiting the invention to products, and it should be noted that 

1 1 the present invention may easily be adapted for the remote purchase of services, as well 

12 as products. Also, the term "messaging address" should be interpreted broadly as 

13 including email addresses, telephone, pager, SMS, or MMS numbers (including 

14 telephone numbers at which a user might be contacted using a synthesized or recorded 

15 voice message), and all other identifiers that may be used to address an electronic 

1 6 communication to a user. 

17 It will be appreciated by those skilled in the art that although the functional 

1 8 components of the exemplary embodiments of the system of the present invention 

19 described herein may be embodied as one or more distributed computer program 

20 processes, data structures, dictionaries and/or other stored data on one or more 

21 conventional general purpose computers (e.g., IBM-compatible, Apple Macintosh, and/or 

22 RISC microprocessor-based computers), mainframes, minicomputers, conventional 

23 telecommunications (e.g., modem, DSL, satellite and/or ISDN communications), memory 
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1 storage means (e.g., RAM, ROM) and storage devices (e.g., computer-readable memory, 

2 disk array, direct access storage) networked together by conventional network hardware 

3 and software (e.g., LAN/WAN network backbone systems and/or Internet), other types of 

4 computers and network resources may be used without departing from the present 

5 invention. One or more networks discussed herein may be a local area network, wide 

6 area network, internet, intranet, extranet, proprietary network, virtual private network, a 

7 TCP/IP-based network, a wireless network (e.g., IEEE 802. 1 1 or Bluetooth), an e-mail 

8 based network of e-mail transmitters and receivers, a modem-based telephonic network, 

9 an interactive telephonic network accessible to users by telephone, or a combination of 

10 one or more of the foregoing. 

1 1 The invention as described herein may be embodied in a computer residing on a 

12 network transaction server system, and input/output access to the invention may comprise 

13 appropriate hardware and software (e.g., personal and/or mainframe computers 

14 provisioned with Internet wide area network communications hardware and software 

15 (e.g., CQI-based, FTP, Netscape Navigator™ or Microsoft Internet Explorer™ HTML 

16 Internet browser software, and/or direct real-time or near-real-time TCP/IP interfaces 

17 accessing real-time TCP/IP sockets) for permitting human users to send and receive data, 

18 or to allow unattended execution of various operations of the invention, in real-time 

19 and/or batch-type transactions. Likewise, the system of the present invention may be a 

20 remote Internet-based server accessible through conventional communications channels 

21 (e.g., conventional telecommunications, broadband communications, wireless 

22 communications) using conventional browser software (e.g., Netscape Navigator™ or 

23 Microsoft Internet Explorer™). Thus, the present invention may be appropriately 
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1 adapted to include such communication functionality and Internet browsing ability. 

2 Additionally, those skilled in the art will recognize that the various components of the 

3 server system of the present invention may be remote from one another, and may further 

4 comprise appropriate communications hardware/software and/or LAN/WAN hardware 

5 and/or software to accomplish the functionality herein described. 

6 Each of the functional components of the present invention may be embodied as 

7 one or more distributed computer program processes running on one or more 

8 conventional general purpose computers networked together by conventional networking 

9 hardware and software. Each of these functional components may be embodied by 

10 running distributed computer program processes (e.g., generated using "full-scale" 

1 1 relational database engines such as IBM DB2™, Microsoft SQL Server™, Sybase SQL 

12 Server ™, Oracle 7.3 ™, or Oracle 8.0 ™ database managers, and/or a JDBC interface to 

13 link to such databases) on networked computer systems (e.g., comprising mainframe 

14 and/or symmetrically or massively parallel computing systems such as the IBM SB2 ™ 

15 or HP 9000 ™ computer systems) including appropriate mass storage, networking, and 

16 other hardware and software for permitting these functional components to achieve the 

17 stated function. These computer systems may be geographically distributed and 

18 connected together via appropriate wide- and local-area network hardware and software. 

19 In one embodiment, program data may be made accessible to the user via standard SQL 

20 queries for analysis and reporting purposes. 

21 Primary elements of the invention may be server-based and may reside on 

22 hardware supporting an operating system such as Microsoft Windows NT/2000™ or 

23 UNIX. 
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1 Clients may include mobile and non-mobile devices. Mobile devices that may be 

2 employed in the present invention include personal digital assistant (PDA) style 

3 computers, e.g., as manufactured by Palm, Inc., of Santa Clara, California, and other 

4 computers running the Palm™ operating system, Windows CE™ handheld computers, or 

5 other handheld computers (possibly including a wireless modem), as well as wireless or 

6 cellular telephones (including GSM phones, J2ME and WAP-enabled phones, Internet- 

7 enabled phones and data-capable smart phones, e.g., the iMODE phone available from 

8 NTT Docomo of Tokyo, Japan), one- and two-way paging and messaging devices, laptop 

9 computers, etc. Other telephonic network technologies that may be used as potential 

10 service channels in a system consistent with the invention include "2.5G" cellular 

1 1 network technologies such as GPRS and EDGE, as well as "3G" technologies such as 

12 CDMAlxRTT and WCDMA2000. Although mobile devices are preferred, traditionally 

13 non-mobile communications devices are also contemplated by the invention, including 

14 personal computers, Internet appliances, set-top boxes, landline telephones, etc. Clients 

15 may also comprise a PC that supports Apple Macintosh™, Microsoft Windows 

1 6 95/98/NT/ME/CE/2000/XP™, a UNIX Motif workstation platform, or other computer 

17 capable of TCP/IP or other network-based interaction. In one embodiment, no software 

18 other than a web browser may be required on the client platform. 

19 Alternatively, the aforesaid functional components may be embodied by a 

20 plurality of separate computer processes (e.g., generated via dBase™, Xbase™, MS 

2 1 Access ™ or other "flat file" type database management systems or products) running on 

22 IBM-type, Intel Pentium™ or RISC microprocessor-based personal computers 

23 networked together via conventional networking hardware and software and including 
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1 such other additional conventional hardware and software as may be necessary to permit 

2 these functional components to achieve the stated functionalities. In this alternative 

3 configuration, since such personal computers typically may be unable to run full-scale 

4 relational database engines of the types presented above, a non-relational flat file "table" 

5 (not shown) may be included in at least one of the networked personal computers to 

6 represent at least portions of data stored by a system according to the present invention. 

7 These personal computers may run the Unix, Microsoft Windows NT/2000 ™ or 

8 Windows 95/98/NT/ME/CE/2000/XP™ operating systems. The aforesaid functional 

9 components of a system according to the present invention may also comprise a 

10 combination of the above two configurations (e.g., by computer program processes 

1 1 running on a combination of personal computers, RISC systems, mainframes, symmetric 

12 or parallel computer systems, and/or other appropriate hardware and software, networked 

13 together via appropriate wide- and local-area network hardware and software). 

14 A system according to the present invention may also be part of a larger 

15 computerized financial transaction system comprising multi-database or multi-computer 

16 systems or "warehouses" wherein other data types, processing systems (e.g., transaction, 

17 financial, administrative, statistical, data extracting and auditing, data 

18 transmission/reception, and/or accounting support and service systems), and/or storage 

19 methodologies may be used in conjunction with those of the present invention to achieve 

20 an overall information management, processing, storage, search, statistical and retrieval 

2 1 solution for a particular lock box service provider, e-payment warehouser, biller 

22 organization, financial institution, payment system, commercial bank, and/or for a 

23 cooperative or network of such systems. 
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1 In one embodiment, source code may be written in an object-oriented 

2 programming language using relational databases. Such an embodiment may include the 

3 use of programming languages such as C++ and toolsets such as Microsoft's .Net™ 

4 framework. Other programming languages that may be used in constructing a system 

5 according to the present invention include Java, HTML, Perl, UNIX shell scripting, 

6 assembly language, Fortran, Pascal, Visual Basic, and QuickBasic. Those skilled in the 

7 art will recognize that the present invention may be implemented in hardware, software, 

8 or a combination of hardware and software. 

9 A system consistent with the present invention may interact with established 

10 payment networks, e.g., the Automated Clearing House (ACH) to provide payment 

1 1 options such as ACH debits, credit or procurement card payments, and/or paper checks. 

12 Paper checks may be generated internally or by an external software module, wherein an 

13 output file in a format capable of being read by the external module may be generated. 

14 Payment by a payer system user using a credit or procurement card may also be effected, 

15 to be processed by Internet or other means. In this scenario, additional security levels 

16 may be included, e.g., for initiating credit card payments (along with a dollar amount 

17 limit) and approving credit card payments, and such appropriate credit card payment 

18 processing functionality as may be appropriate may be included, as well. 

19 It should also be appreciated from the outset that one or more of the functional 

20 components may alternatively be constructed out of custom, dedicated electronic 

21 hardware and/or software, without departing from the present invention. Thus, the 

22 present invention is intended to cover all such alternatives, modifications, and equivalents 

23 as may be included within the spirit and broad scope of the invention. 
24 
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